Antw: [EXT] invalid opcode

[Ulrich Windl]

>>> Stefan Kania  schrieb am 08.03.2023 um 13:47 in
Nachricht <7079926e-76af-748c-0447-d1b503dc0...@kania-online.de>:
> Hi to all,
> 
> I just installed a fresh 2.5 server with the symas-packages and debian 
> 11. I can start the service, but as soon as I try to authenticate for 
> example with:
> 
> ldapsearch -x -D cn=admin,dc=example,dc=net -W
> 
> the server crashes, I put the loglevel to "any" and I saw
> 
>   kernel: traps: slapd[18020] trap invalid opcode ip:7febaf26a415 
> sp:7fc3ad4b69e0 error:0 in libargon2.so.1[7febaf266000+5000]
> 
> Everytime I try to authenitcate. All packages are up to date.
> 
> any idea

Maybe examine the compiler flags, compiler version and CPU running the binary.

Regards,
Ulrich

Re: Antw: [EXT] Re: Entering Multi-Byte Values for DirectoryString attributes

[Ulrich Windl]

>>> Ede Wolf  schrieb am 22.02.2023 um 11:03 in 
>>> Nachricht
<6ad6c4b7-3f7d-3e2b-b1bd-936bd6060...@nebelschwaden.de>:

>> It seems the backslash notation is not actually defined for LDIF.
> 
> That indeed is a valuable hint, out of curiosity I will test, wether 
> other ldap server implementations will also accept at least the \FF 
> notation for the dn, but that is off topic here.
> 
> 
>> RFC 2849 (LDAP Data Interchange Format) says:
>> 
>> SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
>> 
>> SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
>> SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F
> 
> I have come across this way of writing in a couple of rfc, also one 
> about unicode, but the %xFF notation (with or  without the x) never 
> worked for me. Not even within the dn.

You mix notations: %x09 means a literal TAB character for the actual syntax, 
but it is described as %x09 in the language describing the syntax for example. 
The syntax notation is "Crocker, D., and P. Overell, "Augmented BNF for Syntax 
Specifications: ABNF", RFC 2234, November 1997."

Regards,
Ulrich


> 
> dn: cn=A %xF0%x9F%x99%x82 Test,dc=example,dc=com
> 
> Does not work as intended, unless I've made another mistake.
> 
> But as said before, I am a bit overwhelmed with understanding these rfc. 
> Or rather translate them into practical action.
> 
> So far I had only luck with the \FF notation, and only for the dn, which 
> is correct, as I know now.
> 
> But, as mentioned above, I will also test against SDS and 389DS, to 
> figure, wether those will also accept the backslash notation as well.
> 
> Just to see, if this is kind of a defacto standard, even if not 
> hardcoded into a rfc.

Antw: [EXT] Re: Entering Multi-Byte Values for DirectoryString attributes

[Ulrich Windl]

>>> Ede Wolf  schrieb am 21.02.2023 um 16:10 in 
>>> Nachricht
<5fed02ec-1e12-5264-305f-a3f69a335...@nebelschwaden.de>:

>> The same way you would enter Unicode in any other application. This is not 
> an LDAP- or LDIF-specific question.
>> 
>> 1) use a terminal and locale that support UTF-8.
>> 2) use whatever tools your OS provides for entering Unicode characters. 
> Probably something named "Unicode character map" or similar.
>> 
> 
> Thanks again. But my question regards the values for attributes.
> 
> Having a ldif file, for the dn I can enter:
> dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com

It seems the backslash notation is not actually defined for LDIF.

RFC 2849 (LDAP Data Interchange Format) says:

SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]

SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F

dn-spec = "dn:" (FILL distinguishedName / ":" FILL base64-distinguishedName)
distinguishedName = SAFE-STRING
rdn = SAFE-STRING

base64-distinguishedName = BASE64-UTF8-STRING

base64-rdn = BASE64-UTF8-STRING

UTF8-STRING = *UTF8-CHAR

BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
%x61-7A

BASE64-UTF8-STRING = BASE64-STRING

BASE64-STRING = [*(BASE64-CHAR)]


> 
> That would literally give me the utf8 smiley icon as part of my dn - 
> provided my font feratures that, of course.
> So I can use the hex encoding representation to enter any UTF-8 character.
> 
> I can even search for that icon, using that hex encoding as search base 
> or part of the search filter.
> 
> However, for a value, I cannot do this, and my question is, is there a 
> way at all?
> This has nothing to do with my console.
> 
> For a directorystring attribute (it value), is there any way of entering 
> code points straight into my ldif - be it U+ or hex notation - and 
> having the server interpret them, as it works for the dn?
> 
> Not copy+paste from the command line, but, again, as encodigs where the 
> ldap server knows, these are to be interpreted. As it does for the dn.
> 
> Something like:
> cn: A \F0\9F\99\82 Test
> 
> Just with a syntax that works. If that it possible at all.
> 
> Thanks
> 
> Ede

Antw: [EXT] Symas OpenLDAP RE25 and RE26 test packages available

[Ulrich Windl]

>>> Shawn McKinney  schrieb am 03.02.2023 um 00:08 in
Nachricht <92dcba07-e4ea-4c9f-bce1-8f37b6644...@symas.com>:
...
> The following platforms are available:
> 
> - RHEL7/8/9
> - Debian 10/11
> - Ubuntu 18.04/20.04/22.04
> - SLES 15.3

Note: Current is SLES 15.4 (with 15.5 already in beta AFAIK); just a typo?

> 
> Notes: 
> 
> - RHEL9 and Ubuntu 22.04 packages are not yet in the release repo. Both will

> be there after this release.
> - Symas packages are not supported by the OpenLDAP project.
> - Issues directed to supp...@symas.com 
> 
> —
> Shawn

Antw: [EXT] Setting acl on cn=accesslog (accesslog overlay)

[Ulrich Windl]

>>> Simon Kainz  schrieb am 02.02.2023 um 15:57 in 
>>> Nachricht
:
> Hello,
> 
> i am looking for a way to set an ACL entry for cn=accesslog, which is 
> where i am logging the slapo-accesslog overlay entries to.
> 
> I tried to set set it with the following:
> 
> dn: olcDatabase{1}mdb,cn=config
> changeType: modify
> add: olcAccess
> alcAccess: to db.base="cn=accesslog" by 

What if you try "to *" instead? So can you read the auditContainer itself?

> dn.base="cn=ldap_cleanup,o=<>" read by * break
> 
> This operation works, and i see the intry in my slapd config.
> 
> I am still unable to see entries from cn=accesslog.
> 
> Regards,
> 
> Simon

Re: Antw: [EXT] Re: Slow Mod operations on LDAP

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 19.01.2023 um 19:18 in
Nachricht :

> 
> --On Thursday, January 19, 2023 8:25 AM +0100 Ulrich Windl 
>  wrote:
> 
>>>>> Quanah Gibson-Mount  schrieb am 18.01.2023 um
>>>>> 14:50 in
>> Nachricht <3D6804DEBBC5413284159965@[192.168.1.14]>:
>>
>> ...
>>> I would note that it is not advised to use XFS with back-mdb.
>>
>> Would you explain why? Here we use XFS for all database filesystems.
> 
> The filesystem journaling done by XFS is not required for back-mdb 
> databases and imposes a significant performance penalty for write 
> operations.  Unlike ext4 partitions it is not possible to disable the 
> filesystem journal.  The best option for back-mdb databases on XFS is to 
> tell XFS to use a external journal.

OK, but it seems to me that XFS (as most others, too) does metadata journaling 
only. The man page says: "The log section (or area, if it is internal to the 
data section) is used to store changes to filesystem metadata while the 
filesystem is running until those changes are made to the data section."

Also you could set logdev= to a very fast device.

Inspecting the log of our most busy database's redo logs, it does not look as 
if data is in the journal; using xfs_logprint, I got:

xfs_logprint:
xfs_logprint: /dev/mapper/DB--log1 contains a mounted and writable filesystem
data device: 0xfe1c
log device: 0xfe1c daddr: 5242784 length: 20480

log tail: 15104 head: 15200 state: 


LOG REC AT LSN cycle 7883 block 15104 (0x1ecb, 0x3b00)

TRANS: tid:0x37efb8bb  #items:4  trans:0x37efb8bb  q:0x1570870
INO: cnt:2 total:2 a:0x1582320 len:56 a:0x1582360 len:96
INODE: #regs:2   ino:0x84  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1581f00 len:56 a:0x1581f70 len:96
INODE: #regs:2   ino:0x85  flags:0x1   dsize:0
CORE inode:

LOG REC AT LSN cycle 7883 block 15136 (0x1ecb, 0x3b20)

TRANS: tid:0x17345a71  #items:2  trans:0x17345a71  q:0x1570870
INO: cnt:2 total:2 a:0x1581f00 len:56 a:0x1581f70 len:96
INODE: #regs:2   ino:0x85  flags:0x1   dsize:0
CORE inode:

LOG REC AT LSN cycle 7883 block 15168 (0x1ecb, 0x3b40)

TRANS: tid:0xb6533eee  #items:4  trans:0xb6533eee  q:0x1570870
INO: cnt:2 total:2 a:0x1581f00 len:56 a:0x1581f70 len:96
INODE: #regs:2   ino:0x84  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1582320 len:56 a:0x1582360 len:96
INODE: #regs:2   ino:0x85  flags:0x1   dsize:0
CORE inode:
---
to me "dsize:0" looks as if no data is in the entries.

The "data" filesystem seems a bit more busy:
xfs_logprint:
xfs_logprint: /dev/mapper/DB--data contains a mounted and writable filesystem
data device: 0xfe1b
log device: 0xfe1b daddr: 1258290720 length: 1228800

log tail: 404544 head: 404608 state: 


LOG REC AT LSN cycle 151 block 404544 (0x97, 0x62c40)

TRANS: tid:0x58198a01  #items:136  trans:0x58198a01  q:0x1b24870
INO: cnt:2 total:2 a:0x1b36320 len:56 a:0x1b36360 len:96
INODE: #regs:2   ino:0x400056c1  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b35f00 len:56 a:0x1b35f70 len:96
INODE: #regs:2   ino:0x1e0032bb1  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3e410 len:56 a:0x1b3e4b0 len:96
INODE: #regs:2   ino:0x100f0fbb  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3e520 len:56 a:0x1b3e5c0 len:96
INODE: #regs:2   ino:0xa0017c68  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3e630 len:56 a:0x1b3e6d0 len:96
INODE: #regs:2   ino:0x200068a0  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3e740 len:56 a:0x1b3e7e0 len:96
INODE: #regs:2   ino:0x180001fb1  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3e850 len:56 a:0x1b3e8f0 len:96
INODE: #regs:2   ino:0xe0002221  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3e960 len:56 a:0x1b3ea00 len:96
INODE: #regs:2   ino:0xc056db7f  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3ea70 len:56 a:0x1b3eb10 len:96
INODE: #regs:2   ino:0x87534f87  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3eb80 len:56 a:0x1b3ec20 len:96
INODE: #regs:2   ino:0x100f0fbf  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3ec90 len:56 a:0x1b3ed30 len:96
INODE: #regs:2   ino:0xb0006f44  flags:0x1   dsize:0
CORE inode:
INO: cnt:2 total:2 a:0x1b3eda0 len:56 a:0x1b3ee40 len:96
INODE: #regs:2   ino:0x4d6f1  flags:0x

Antw: [EXT] Re: Slow Mod operations on LDAP

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 18.01.2023 um 14:50 in
Nachricht <3D6804DEBBC5413284159965@[192.168.1.14]>:

...
> I would note that it is not advised to use XFS with back-mdb.

Would you explain why? Here we use XFS for all database filesystems.

Regards,
Ulrich

Antw: [EXT] Re: Q: incrementally adding LDIF entries using ldapadd

[Ulrich Windl]

>>> Howard Chu  schrieb am 17.01.2023 um 17:40 in Nachricht
:
> Ulrich Windl wrote:
>> Hi!
>> 
>> I'm working on a program that "mangles" existing LDIF files so that the LDAP 
> server accepts them.
>> So say 75% passed, 25% had errors (need additional fixes).
>> 
>> I'm using ldapadd with "-c" (continue) and "-S skipped.ldif" (skipped 
> entries) to add the input LDIF.
>> 
>> The idea was to iterate over skipped.ldif until the file is empty, i.e.: 
> make skipped.ldif the new input file for the next run of ldapadd.
>> However "skipped.ldif" also contains entries that were skipped, because they 
> had been imported (successfully) before ("ldap_add: Already exists (68)").
>> 
>> Is there an easy way to extract only those entries that were not added?
>> 
>> Of course I could write a program that implements that logic, talking to the 
> LDAP server directly, but if avoidable I'd save the time to write such a 
> program.
> 
> Don't use -c, fix errors as they appear, and use -j to resume.

Thanks, unfortunately my versions of ldapadd don't have that option yet.

> 
> 
> -- 
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com 
>   Director, Highland Sun http://highlandsun.com/hyc/ 
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/ 

Q: incrementally adding LDIF entries using ldapadd

[Ulrich Windl]

Hi!

I'm working on a program that "mangles" existing LDIF files so that the LDAP 
server accepts them.
So say 75% passed, 25% had errors (need additional fixes).

I'm using ldapadd with "-c" (continue) and "-S skipped.ldif" (skipped entries) 
to add the input LDIF.

The idea was to iterate over skipped.ldif until the file is empty, i.e.: make 
skipped.ldif the new input file for the next run of ldapadd.
However "skipped.ldif" also contains entries that were skipped, because they 
had been imported (successfully) before ("ldap_add: Already exists (68)").

Is there an easy way to extract only those entries that were not added?

Of course I could write a program that implements that logic, talking to the 
LDAP server directly, but if avoidable I'd save the time to write such a 
program.

Regards,
Ulrich

Antw: [EXT] newer TLS clients (> 3.0?) can't connect to OpenLDAP's TLS with SSSD

[Ulrich Windl]

Hi!

As you use IP addresses to connect, do your certificates specify those IP 
addresses as alternate subjects, too?


Regards,
Ulrich

>>> Jarett DeAngelis  schrieb am 09.01.2023 um 22:10 in
Nachricht <768dfc4e-53a9-4f05-ad61-61c00ed52...@bioteam.net>:
> hi - using OpenLDAP 2.6.3 and finding that newer LDAP client libraries (like 
> the one that comes with Ubuntu 22.04.1 LTS) can't complete a connection to 
> the LDAP server's TLS port. A machine I have running Rocky 8.6, however, with 
> OpenSSL 1.1.1k, connects just fine. This is using self-generated 
> certificates, but the correct CA cert and server cert have been provided to 
> SSSD to use for login. The two machines are using identical certificates and 
> SSSD configuration files.
> 
> How do we begin to troubleshoot this? The trouble is seen in the SSSD log:
> 
> (2023-01-09 21:08:26): [be[default]] [fo_resolve_service_send] (0x0100): 
> [RID#13] Trying to resolve service 'LDAP'
> (2023-01-09 21:08:26): [be[default]] [get_server_status] (0x1000): [RID#13] 
> Status of server '10.8.8.60' is 'name not resolved'
> (2023-01-09 21:08:26): [be[default]] [get_port_status] (0x1000): [RID#13] 
> Port status of port 636 for server '10.8.8.60' is 'neutral'
> (2023-01-09 21:08:26): [be[default]] [fo_resolve_service_activate_timeout] 
> (0x2000): [RID#13] Resolve timeout [dns_resolver_timeout] set to 6 seconds
> (2023-01-09 21:08:26): [be[default]] [get_server_status] (0x1000): [RID#13] 
> Status of server '10.8.8.60' is 'name not resolved'
> (2023-01-09 21:08:26): [be[default]] [set_server_common_status] (0x0100): 
> [RID#13] Marking server '10.8.8.60' as 'resolving name'
> (2023-01-09 21:08:26): [be[default]] [check_if_online_delayed] (0x2000): 
> [RID#12] Check online req created.
> (2023-01-09 21:08:26): [be[default]] [set_server_common_status] (0x0100): 
> [RID#13] Marking server '10.8.8.60' as 'name resolved'
> (2023-01-09 21:08:26): [be[default]] [be_resolve_server_process] (0x1000): 
> [RID#13] Saving the first resolved server
> (2023-01-09 21:08:26): [be[default]] [be_resolve_server_process] (0x0200): 
> [RID#13] Found address for server 10.8.8.60: [10.8.8.60] TTL 7200
> (2023-01-09 21:08:26): [be[default]] [sdap_uri_callback] (0x0400): [RID#13] 
> Constructed uri 'ldaps://10.8.8.60:636'
> (2023-01-09 21:08:26): [be[default]] [sssd_async_socket_init_send] (0x4000): 
> [RID#13] Using file descriptor [23] for the connection.
> (2023-01-09 21:08:26): [be[default]] [sssd_async_socket_init_send] (0x0400): 
> [RID#13] Setting 60 seconds timeout [ldap_network_timeout] for connecting
> (2023-01-09 21:08:26): [be[default]] [sss_ldap_init_sys_connect_done] 
> (0x0020): [RID#13] ldap_install_tls failed: [Connect error] [unknown error]
> (2023-01-09 21:08:26): [be[default]] [sss_ldap_init_state_destructor] 
> (0x0400): [RID#13] calling ldap_unbind_ext for ldap:[0x55c44d26c1b0] sd:[23]
> (2023-01-09 21:08:26): [be[default]] [sss_ldap_init_state_destructor] 
> (0x0400): [RID#13] closing socket [23]
> (2023-01-09 21:08:26): [be[default]] [sdap_sys_connect_done] (0x0020): 
> [RID#13] sdap_async_connect_call request failed: [5]: Input/output error.
> (2023-01-09 21:08:26): [be[default]] [sdap_handle_release] (0x2000): 
> [RID#13] Trace: sh[0x55c44d24a740], connected[0], ops[(nil)], ldap[(nil)], 
> destructor_lock[0], release_memory[0]
> (2023-01-09 21:08:26): [be[default]] [_be_fo_set_port_status] (0x8000): 
> [RID#13] Setting status: PORT_NOT_WORKING. Called from: 
> ../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1633
> (2023-01-09 21:08:26): [be[default]] [fo_set_port_status] (0x0100): [RID#13] 
> Marking port 636 of server '10.8.8.60' as 'not working'
> (2023-01-09 21:08:26): [be[default]] [fo_set_port_status] (0x0400): [RID#13] 
> Marking port 636 of duplicate server '10.8.8.60' as 'not working'
> 
> Thanks,
> Jarett

Antw: [EXT] OpenLDAP stats logging performance degradation

[Ulrich Windl]

>>> Christopher Paul  schrieb am 31.12.2022 um 
>>> 00:35
in Nachricht


> 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.

Did you try to revert systemd logging to ramdisk only (/run/log/journal/ (or 
so)) instead of /var/log/journal/?

> 
> 
> 
> 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.

Maybe try each single bit of olcLogLevel to make a histogram which logging bit 
consumes most time.
That would be 8 tests (for 8 bits).

> 
> 
> 
> 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.

Well, in general extra logging does not only mean some extra log output, but 
also formatting (like using printf()) or other conversions that may cost extra 
time. There are also profiling tools (like gprof) that might allow you some 
deeper insights, but that would require a rebuild of the software.

Regards,
Ulrich

Re: [EXT] Re: slappasswd generating a supposedly incorrect password hash (only when using {SHA256})

[Ulrich Windl]

Hi!

Maybe the binary or build process should use a test vector to warn if that 
produces the wrong result, assuming the problem is the SHA code itself.

Regards,
Ulrich

29.12.2022 00:39:44 Howard Chu :

> Ralf Hildebrandt wrote:
>> 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?
>> 
> The source code for the pw-sha2 module hasn't changed since 2015 at least. 
> There's no difference between 2.4 and 2.5.
> 
> The variable here is your OS and compiler versions. I get the same result as 
> you on ubuntu 22 with the
> default compile options. If I compile the module with only "-g" and no 
> optimization, I get a different
> result. So the compiler is doing something screwy.
> 
> Note that the sha2.c used in the pw module comes from 
> https://aarongifford.com/computers/sha.html and is
> unmodified. Probably you should report a bug to the gcc project.
> 
> -- 
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com
>   Director, Highland Sun http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Antw: [EXT] Re: lloadd Proxied Authorization Denied (123)

[Ulrich Windl]

>>> Stefan Kania  schrieb am 15.12.2022 um 18:55 in
Nachricht <4c04e864-2b72-c9d2-96b9-036c11f58...@kania-online.de>:

> 
> Am 15.12.22 um 17:56 schrieb Quanah Gibson-Mount:
>> 
>> 
>> --On Thursday, December 15, 2022 3:02 PM +0100 Stefan Kania 
>>  wrote:
>> 
>>> --
>>> dn: cn=config
>>> changetype: modify
>>> replace: olcAuthzpolicy
>>> olcAuthzpolicy: any
>>> --
>> 
>> Since you only need it to be possible for the lloadd user to assume 
>> other identities, I'd use a policy of 'to' instead of 'any'.
>> 
>> --Quanah
>> 
>>
> Thank you, I will change it. Setting it to "any" was just an act of 
> desperation ;-) To get it work.Now comes security and fine tuning

Once you have a transition from "working" to "no longer working" it's easier to 
find out what you might have done wrong, rather than starting with a state "not 
working" ;-)


>> 
>> 
>> 

Antw: [EXT] Detecting replication delay when replicating a subset of data

[Ulrich Windl]

>>>  schrieb am 12.12.2022 um 16:47 in 
>>> Nachricht
<20221212154750.5262.89...@hypatia.openldap.org>:
> Hello,
> 
> Under typical circumstances we run a config database and have a single 
> application database for ldap data. We run consumers replicating from 
> providers where they replicate the entire application database. We detect 
> delayed replication by querying consumer CSNs and comparing them to the 
> provider CSNs to determine if any consumers have delayed replication through 
> a health check script that executes every few minutes.
> 
> For one particular use case we replicate a subset of the application 
> database, but our replication check cannot work for this use case. It appears 
> because we're not replicating the entire database we do not copy the provider 
> CSNs over to the consumers (which live at the base level, and we're copying a 
> DIT below that level) and therefore I cannot ask the consumers what their 
> 'latest csn' is since they do not seem to have one.
> 
> Is there any recommended way I can check that the consumer replication is 
> functioning properly when replicating a subset of the provider database?

My guess is to compute the maximum of all replicated EntryCSNs on the provider 
side and compare them with the maximum of the same entries on the consumer 
side. Or have a test entry you "touch" and compare the EntryCSN of that test 
entry.

> 
> Thanks for the consideration.
> Tom

Q: Length of {SSHA} encoded passwords

[Ulrich Windl]

Hi!

Examining changes of the database via LDIF, I noticed one thing:
-userPassword: {SSHA}XY94+nfFELR3iy0AYTsS0DHqxIOwFNz79zcnniA==
+userPassword: {SSHA}yt98Od1WHak3kYIyZWYoCewg4D+f9ffp

I had thought that the encoded SSHA passwords all have the same length.
Could it depend on the program being used to vhnage the password, thus varying 
the length of salt?
How could I decode that?
(not that the example is not a real one (some characters permutated), so don't 
waste your time trying to crack it)

Regards,
Ulrich

Antw: [EXT] Re: SSSD looking for password policy: "unrecognized control"

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 01.11.2022 um 20:54
in
Nachricht :

> 
> ‑‑On Tuesday, November 1, 2022 7:16 PM + jar...@bioteam.net wrote:
> 
>> Hi,
>>
>> I am attempting to have SSSD do logins to my OpenLDAP 2.6.3 installation,
>> however, I get "permission denied" when trying to log in because SSSD is
>> asking for a password policy, which the server does not appear to have by
>> default. Notably, we don't really care what "policy" the server will
>> claim to have, because password authentication is delegated via SASL to
>> another server which ensures strong passwords. So I just need something
>> that will "get past" whatever checks SSSD is doing. What LDIF config can
>> I add to my configuration to allow SSSD to let users log in properly?
> 
> You could simply load the ppolicy overlay in you configuration so that the 
> control is available, regardless of whether you intend to use it.
> 
> However nothing in the log you provided shows there was any issue due to 
> SSSD requesting it.
> 
> The BIND operation was successful:
> 
> Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97 
> err=0 qtime=0.28 etime=0.000136 text=
> 
> 
> The SEARCH operation was successful:
> 
> Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SEARCH RESULT 
> tag=101 err=0 qtime=0.16 etime=0.000326 nentries=0 text=
> 
> 
> The biggest issue seems to be that it is configured to send invalid search 
> filters, causing ZERO results to be returned (nentries=0 above):
> 
> ov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH 
> base="ou=users,dc=clab,dc=lab" scope=2 deref=0 
> filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=de>
> Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH 
> attr=objectClass objectClass cn sudoCommand sudoHost sudoUser sudoOption 
> sudoRunAs sudoRunAsUser sudoRunAs>
> 
> 
> Note that "sudoRole" objectClass, "sudoHost" attribute is not found.  Note 
> that "cn=de>" is not a valid filter.

For some strange reason sssd starts do query the sudo schema, even if it was
not configured on the server, typically flooding the logs with invalid
requests.
I added the schema here, just to silence the errors...

> 
> Regards,
> Quanah

Two notes on slapppasswd (old version)

[Ulrich Windl]

Hi!

When using an old version (from 2.4.41) of slapasswd, I noticed two things:

1) Using "-h SSHA", slappasswd was asking for passwords first, then telling me: 
"Password generation failed for scheme SSHA: scheme not recognized"

I think "SSHA" is unique enough to recognize; and if it's not, then complain 
before asking for passwords.

2) When I mistyped the option as "-h '{SSHA}>'", slappasswd did not complain 
and produce some output.

I think if it's picky on the first case, it should also be for the second case 
(assuming the output "{SSHA}oTEDKWKn0fimGo6J8de0I5qRixGWJxhJ" was correct 
overall)

Maybe check if these problems still exist in the current version.

Regards,
Ulrich Windl

Antw: [EXT] Re: [OldapWS] ‑> Proposal of a REST Web Service for CRUD Operations

[Ulrich Windl]

>>> Norman Gray  schrieb am 19.09.2022 um 20:44 in Nachricht
<55d788c7-f3d6-4389-bc24-a26318af0...@nxg.name>:

> Greetings.
> 
> On 19 Sep 2022, at 17:54, Howard Chu wrote:
> 
>> Then, I would like to propose a full Open Source first realease of a CRUD 
> REST Web Service to manipulate OpenLDAP's Directory Objects.
> 
> This is a nice idea!
> 
> However, as something of a terminology quibble, I'd say this was a 'web 
> service', rather than a 'REST web service'.
> 
> As I understand the term, I take 'REST' to refer to a web service which, at

> a minimum,
> 
>   * describes a URL‑based scheme for _naming_ the things being manipulated,

> and
>   * retrieves and manipulates those things via the HTTP verbs, GET, POST, 
> PUT, DELETE, etc.
> 
> Thus the 'JSON query string' sent to the server via HTTP POST wouldn't 
> qualify as 'REST'.

OTOH it will help to keep URIs short and allow easy encoding of structured
data.

...

Regards,
Ulrich

Re: Antw: [EXT] Re: how to add index in replication scenario

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 15.09.2022 um 18:09
in
Nachricht <1F341BC71D7ADCBA8A4880D3@[192.168.1.17]>:
> ‑‑On Thursday, September 15, 2022 5:49 PM +0100 Howard Chu  
> wrote:
> 
> 
>> There's nothing to wait for. Index generation is in a background thread,
>> it doesn't block cn=config. ‑‑
> 
> 
> On a large DB, it can take several hours until the index is actually ready 
> for use.  So if you need it to be functional, it's better to slapindex ‑q.

But in both cases you can't use it before the index is done. I don't see the
big difference.

Regards,
Ulrich

> 
> ‑‑Quanah

Antw: [EXT] Re: how to add index in replication scenario

[Ulrich Windl]

>>> Uwe Sauter  schrieb am 14.09.2022 um 17:46 in
Nachricht <449ea0c3-97d9-7228-ef16-a36022c32...@gmail.com>:
>>  Stop server 1
>> change slapd.conf
>> slapindex -q -f /path/to/slapd.conf -b "your base" 
>> start server 1
>> 
>> stop server 2
>> change slapd.conf
>> slapindex -q -f /path/to/slapd.conf -b "your base" 
>> start server 2
>> 
>> 
>> Neither server cares about the indexing in place on the other server.  The 
> main issue would be that
>> queries that are expecting the index to exist will be slow until it is in 
> place.
>> 
>> --Quanah
> 
> 
> Thanks Quanah, worked like a charm.
> 
> I wasn't sure wether indexing would be sync'd between servers.

Using cn=config with replcated configs it's sufficient to add the index to the 
config: The index is created on each server then.

> 
> Regards,
> 
>   Uwe

Re: Antw: [EXT] Re: LMDB 1.0 data.mdb format stability

[Ulrich Windl]

>>> Howard Chu  schrieb am 08.09.2022 um 17:30 in Nachricht
:
> Ulrich Windl wrote:
>>>>> Howard Chu  schrieb am 08.09.2022 um 01:34 in Nachricht
>> <4bc80e7e-17f9-b385-6b11-2aab806ed...@symas.com>:
>>> Steffen Michels wrote:
>>>> Hi,
>>>>
>>>> We are considering using the mdb.master3 branch of LMDB, but it is not 
>>>> clear 
> 
>>> to me whether the data.mdb format will remain stable. Is there a chance that
>>>> another migration of all databases will be required in the future when 
>>> switching now?
>>>
>>> Yes. It is still unreleased because additional changes to the freelist 
>>> format are planned,
>>> and possibly a few other changes.
>>>
>>> In any case, mdb_dump/mdb_load will always work for migrating to a new 
>>> version.
>> 
>> I think at some point an inplace upgrade would be the way to go.
>> On Linux filesystems, you could even upgrade yout ext3 to btrfs ;-)
> 
> That will never happen here. Supporting an in-place upgrade requires the 
> library to support
> old and new formats simultaneously, which is a waste of RAM. Anything that 
> pushes the object
> code size of the hot path over 64KB is a non-starter.

First, the so much criticized bdb could do that also, and second I don't think 
that a one-time conversion would be part of the code "hot path".

>> 
>> Regards,
>> Ulrich
>> 
>>>
>>>>
>>>> regards,
>>>>
>>>> Steffen
>>>
>>>
>>> -- 
>>>   -- Howard Chu
>>>   CTO, Symas Corp.   http://www.symas.com 
>>>   Director, Highland Sun http://highlandsun.com/hyc/ 
>>>   Chief Architect, OpenLDAP  http://www.openldap.org/project/ 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com 
>   Director, Highland Sun http://highlandsun.com/hyc/ 
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/ 

Re: Antw: [EXT] Re: LMDB 1.0 data.mdb format stability

[Ulrich Windl]

>>> Søren Holm  schrieb am 08.09.2022 um 20:23 in Nachricht
:

> Den 08.09.2022 kl. 18.20 skrev Howard Chu:
>> Søren Holm wrote:
>>>
>>>
>>> Den 08.09.2022 kl. 17.30 skrev Howard Chu:
>>>> Ulrich Windl wrote:
>>>>>>>> Howard Chu  schrieb am 08.09.2022 um 01:34 in
Nachricht
>>>>> <4bc80e7e-17f9-b385-6b11-2aab806ed...@symas.com>:
>>>>>> Steffen Michels wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We are considering using the mdb.master3 branch of LMDB, but it is not
clear
>>>>>> to me whether the data.mdb format will remain stable. Is there a chance
that
>>>>>>> another migration of all databases will be required in the future
when
>>>>>> switching now?
>>>>>>
>>>>>> Yes. It is still unreleased because additional changes to the freelist
>>>>>> format are planned,
>>>>>> and possibly a few other changes.
>>>>>>
>>>>>> In any case, mdb_dump/mdb_load will always work for migrating to a new
>>>>>> version.
>>>>>
>>>>> I think at some point an inplace upgrade would be the way to go.
>>>>> On Linux filesystems, you could even upgrade yout ext3 to btrfs ;-)
>>>>
>>>> That will never happen here. Supporting an in-place upgrade requires the

> library to support
>>>> old and new formats simultaneously, which is a waste of RAM. Anything
that 
> pushes the object
>>>> code size of the hot path over 64KB is a non-starter.
>>>
>>> Well - if the old version is kept in it's own memory region the new
version 
> will still fit within it's own 64KB region.
>>>
>>> If the library should not contain both how would you image an application

> managing the upgrade by itself. I mean, the symbols are names the same etc.

> so it is
>>> difficult to link with both the old and new version.
>> 
>> A database upgrade is an administrative change, thus handled by the 
> administrative tools mdb_dump/mdb_load.
>> There's no need to handle it in an application's main runtime code.
> 
> Are you sure about that? Let's say that fx. Firefox of SQlite (v4 will 
> be on top of LMDB afaik) starts using LMDB for internal storage. Asking 
> the user to run the administrative tools is a bit much. A software 
> controlled migration path is crucial.

Also I think the size of SQlite database as use in Firefox would qualify as
"toy database" (a few MB at most, if at all).
So I'm surprised that Firefox switches the "database". Real databases have
diffetent requirements when extended downtimes are not always an option.
Firefox is not a good example here IMHO.

Regards,
Ulrich

> 
> --
> Søren Holm

Antw: Re: [EXT] Re: Q: "Error: Invalid DN syntax (34), additional info: invalid new RDN"

[Ulrich Windl]

>>> Ulrich Windl  schrieb am 28.08.2022 um
18:08
in Nachricht :
> Hi!
> 
> Good catch! I overlooked that! I'll try with that change and report.

Of course that was it! Worked now. Sorry for the noise, but I didn't see it
before, even when looking at it.

> 
> Thanks,
> Ulrich
> 
> 26.08.2022 21:09:16 John C. Pfeifer :
> 
>> Doesn’t it need to be:
>> 
>> newrdn: cn=subntbcst-tftp@247/tcp
>> 
>> //
>> John Pfeifer
>> Division of Information Technology
>> University of Maryland, College Park
>> 
>>> On Aug 26, 2022, at 7:29 AM, Ulrich Windl
 
> wrote:
>>> 
>>> Hi!
>>> 
>>> I'm programming some automated changes to our LDAP database, and I have
an
>>> issue:
>>> 
>>> # Error: Invalid DN syntax (34), additional info: invalid new RDN
>>> dn: cn=subntbcst_tftp@247/tcp,dc=services,dc=net,dc=...,dc=de
>>> changetype: modrdn
>>> newrdn: subntbcst-tftp@247/tcp
>>> deleteoldrdn: 1
>>> 
>>> So is the new RDN "subntbcst-tftp@247/tcp" really invalid? If so it seems
an
>>> older version of OpenLDAP accepted that as we have such an entry:
>>> 
>>> dn: cn=subntbcst_tftp@247/tcp,dc=services,dc=net,dc=...,dc=de
>>> objectClass: ipService
>>> cn: subntbcst_tftp
>>> cn: subntbcst_tftp@247/tcp
>>> createTimestamp: 20130719093351Z
>>> ...
>>> 
>>> I saw this exaple in RFC 2849 (so I thought my LDIF shuld be OK):
>>> 
>>> # Modify an entry’s relative distinguished name
>>> dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
>>> changetype: modrdn
>>> newrdn: cn=Paula Jensen
>>> deleteoldrdn: 1
>>> 
>>> Regards,
>>> Ulrich
>>> 
>>> 

Re: [EXT] Re: Q: "Error: Invalid DN syntax (34), additional info: invalid new RDN"

[Ulrich Windl]

Hi!

Good catch! I overlooked that! I'll try with that change and report.

Thanks,
Ulrich

26.08.2022 21:09:16 John C. Pfeifer :

> Doesn’t it need to be:
> 
> newrdn: cn=subntbcst-tftp@247/tcp
> 
> //
> John Pfeifer
> Division of Information Technology
> University of Maryland, College Park
> 
>> On Aug 26, 2022, at 7:29 AM, Ulrich Windl 
>>  wrote:
>> 
>> Hi!
>> 
>> I'm programming some automated changes to our LDAP database, and I have an
>> issue:
>> 
>> # Error: Invalid DN syntax (34), additional info: invalid new RDN
>> dn: cn=subntbcst_tftp@247/tcp,dc=services,dc=net,dc=...,dc=de
>> changetype: modrdn
>> newrdn: subntbcst-tftp@247/tcp
>> deleteoldrdn: 1
>> 
>> So is the new RDN "subntbcst-tftp@247/tcp" really invalid? If so it seems an
>> older version of OpenLDAP accepted that as we have such an entry:
>> 
>> dn: cn=subntbcst_tftp@247/tcp,dc=services,dc=net,dc=...,dc=de
>> objectClass: ipService
>> cn: subntbcst_tftp
>> cn: subntbcst_tftp@247/tcp
>> createTimestamp: 20130719093351Z
>> ...
>> 
>> I saw this exaple in RFC 2849 (so I thought my LDIF shuld be OK):
>> 
>> # Modify an entry’s relative distinguished name
>> dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
>> changetype: modrdn
>> newrdn: cn=Paula Jensen
>> deleteoldrdn: 1
>> 
>> Regards,
>> Ulrich
>> 
>> 

Q: "Error: Invalid DN syntax (34), additional info: invalid new RDN"

[Ulrich Windl]

Hi!

I'm programming some automated changes to our LDAP database, and I have an
issue:

# Error: Invalid DN syntax (34), additional info: invalid new RDN
dn: cn=subntbcst_tftp@247/tcp,dc=services,dc=net,dc=...,dc=de
changetype: modrdn
newrdn: subntbcst-tftp@247/tcp
deleteoldrdn: 1

So is the new RDN "subntbcst-tftp@247/tcp" really invalid? If so it seems an
older version of OpenLDAP accepted that as we have such an entry:

dn: cn=subntbcst_tftp@247/tcp,dc=services,dc=net,dc=...,dc=de
objectClass: ipService
cn: subntbcst_tftp
cn: subntbcst_tftp@247/tcp
createTimestamp: 20130719093351Z
...

I saw this exaple in RFC 2849 (so I thought my LDIF shuld be OK):

# Modify an entry’s relative distinguished name
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: cn=Paula Jensen
deleteoldrdn: 1

Regards,
Ulrich

Antw: [EXT] measurable slower result time with large subtree

[Ulrich Windl]

>>> Norbert  schrieb am 24.08.2022 um 11:27 in Nachricht
<7c7bb2e6-d037-7069-9e32-0851e685c...@freakix.de>:
> Hi,
> 
> with OpenLDAP 2.4.47 (running on Debian 10) but also with 2.5.13 from 
> ltb-project.org (running on same Debian 
> 10) I can observe the following:
> 
> given following rough idea of a tree
> 
> o=base
>|- bn=subtree1
>|- handful of entries
>|- bn=subtree2
>|- millions of entries
>|- bn=subtree3
>||- bn=sub-subtree1
>||- bn=sub-subtree2
>||- some entries
>|- bn=subtree4
> 
> ou is an indexed attribute with pres,eq,sub. When now searching with the 

And is bn indexed, too?

> filter bn= then there is a 
> significant difference when searching for either subtree1 and subtree2 as 
> values in the range of seconds. This 
> means on command line ldapsearch with subtree1 it is around 0.007 seconds 
> and with subtree2 4.5 seconds before 
> the fully finishes.
> 
> When I change the search filter to "(&(objectClass=bnClass)(bn=))" 
> then 
> this has no real impact to the 
> time needed searching for subtree1 but improves searching subtree2, still it 
> more than 2 times slower than 
> searching for subtree1. Only entries with objectClass=bnClass have the bn 
> attribute but no other entries.
> 
> Changing the scope to one, yields similar times when searching for subtree1 
> and subtree2 but the search itself 
> also to cover searching for sub-subtree1 or sub-subtree2 with the same 
> search task as it is not known where 
> such sub-subtree could be found.
> 
> The only pattern I've found so far is that if there are millions of entries 
> in a subtree then finishing the 
> search takes much longer.
> 
> The LDAP is using MDB, and has been completely rebuilt (means 
> slapcat/slapadd) several times with always 
> showing the same results. There was no difference between 2.4 and 2.5.13.
> 
> Is there something which can be improved by changing the configuration?
> 
> Thanks,
> Norbert

ipService anyone?

[Ulrich Windl]

Hi!

Several years ago I added ipService to our LDAP Database, then I thought it's 
time to update it.
Now I have a conceptual problem:
Some services have multiple protocols and port numbers. For example 
"compressnet".

While it's possible to assign unique names like
cn=compressnet@2/tcp,...
cn=compressnet@2/tcp,...
cn=compressnet@3/tcp,...
cn=compressnet@3/udp,...

I wonder how a standard query for "compressnet" should look like.
Basically I'd like to leave out the port (@n), but the IANA registry is not 
unique.
I identified these:
compressnet
mit-ml-dev
sql-net
rap
meter
pip
csdmbase
csdm
nmsp
uma
raid-cd
...
optohost004

It seems ipService can have multiple values for ipServiceProtocol, cn, and 
ipServiceProtocol, but wouldn't that silently assume that all port numbers are 
valid for all listed protocols? For the example it would be any combination of 
(UDP,TCP) and (2,3).

To me the only solution seems to force IANA to clean up the mess.

RFC-6335/BCP-165 claims: "Service names are the unique key in the Service Name 
and Transport Protocol Port Number registry." (page 8)

Opinions?

Regards,
Ulrich

Antw: RE: [EXTERNAL] Antw: [EXT] OpenLDAP 2.6 is holding connections open

[Ulrich Windl]

>>> Bradley T Gill  schrieb am 28.07.2022 um 14:17 in Nachricht
<6777136244004f3ba0fd72253ee0e...@aep.com>:
> Ulrich,
>   Thanks for the response.  I have been considering that setting, but it
is 
> unchanged from the previous version.  I am concerned that it might break 
> applications that are expecting a persistent connection.   It also seems to

> be growing so fast that there is a fundamental change somewhere.  

Hi!

I had similar concerns; that's why I used the large value. But as an LDAP
server can go down, clients should be able to handle if a connection goes
down.
Also (as I understand it), one request per day would keep the connection
alive. OTOH: Does a connection that is not transferring a single packet within
24 hours have a justification to exist (consuming system resources on the
server)?

>   I will add that I found that some overlay configs were missing
including a 
> relay for Oracle searches.  I am hoping that not knowing how to handle the 
> requests created the problem.  Now that it is fixed, I am monitoring the 
> ports.

Maybe try step 1: Who is opening those connections (on the client)? "netstat
-tnp" on Linux if you still have netstat.

Regards,
Ulrich

> 
> Thanks,
> Bradley Gill, CISSP, CCSP
> 
> -Original Message-
> From: Ulrich Windl  
> Sent: Thursday, July 28, 2022 5:35 AM
> To: Bradley T Gill ; openldap-technical@openldap.org 
> Subject: [EXTERNAL] Antw: [EXT] OpenLDAP 2.6 is holding connections open
> 
> This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN 
> attachments. If suspicious please click the 'Report to Incidents' button in

> Outlook or forward to incide...@aep.com from a mobile device.
> 
>>>> Bradley T Gill  schrieb am 27.07.2022 um 15:59 in 
>>>> Nachricht
> <84030354e2e44d13b5463c6c070e3...@aep.com>:
>> 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
> 
> What about "olcIdleTimeout: 86400" (or even more aggressive)?
> In the past we had cases where applications opened new LDAP connections, 
> never reused or closed old ones.
> 
>> 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

Antw: [EXT] OpenLDAP 2.6 is holding connections open

[Ulrich Windl]

>>> Bradley T Gill  schrieb am 27.07.2022 um 15:59 in Nachricht
<84030354e2e44d13b5463c6c070e3...@aep.com>:
> 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

What about "olcIdleTimeout: 86400" (or even more aggressive)?
In the past we had cases where applications opened new LDAP connections, never
reused or closed old ones.

> 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

Antw: [EXT] Re: pwdChangedTime range query

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 12.07.2022 um 18:19
in
Nachricht :

> 
> ‑‑On Tuesday, July 12, 2022 1:31 PM +0200 Francesco Malvezzi 
>  wrote:
> 
>> [...]
>>>
>>> Whatever "it works" really means. Without seeing example entries and
>>> their pwdChangedTime values it's impossible to say anything meaningful ‑
>>> except the usual "it works for me".
>>
>> it turns out this malfunctioning is affecting only entries whose password
>> has been changed last time before the upgrade [1].
>>
>> So to be sure that 'it works for you' you should pick a pretty old entry
>> and craft the range pwdChangedTime query accordingly.
>>
>> And of course this applies to you only if you did a in‑place update. If
>> you slapcat‑ed and slapadd‑ed your entries, you are pretty safe,
> 
> This is due to ITS#9513 which changed the generalizedTime indexer.  So any 
> time‑based attributes need to be reindexed (or database exported/imported 
> will fix it too).  This got missed being documented on the OpenLDAP side. 
> Can also affect replication when an in‑place upgrade is done.

Can't that be detected and fixed automatically?

> 
> 
> Regards,
> Quanah

Re: Antw: [EXT] How to relay read and write requests to different ldap servers

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 22.06.2022 um 17:29
in
Nachricht :

> 
> ‑‑On Wednesday, June 22, 2022 9:03 AM +0200 Ulrich Windl 
>  wrote:
> 
>> Ignoring the loadbalancer issues, I think you add a race condition when
>> reading possibly older data from your consumers and maybe write them back
>> where newer data may exist already (i.e.: providers). BTW: Is a modify
>> operation a read, or is it a write?
> 
> modify ops are always a write operation, since they are doing a 
> modification.

Sorry, I was not precise enough:
What I wanted to ask was: Is the "modify" the user was talking about a
LDIF-like modify, or is it a user-level modify like reading data from one
source, manipulating the data and then write that data to a possibly different
destination. The latter case is probably opening a can of worms, so to say.

> 
> And yes, read‑after‑write can be a tricky issue to handle.
> 
> ‑‑Quanah

Antw: [EXT] How to relay read and write requests to different ldap servers

[Ulrich Windl]

>>>  schrieb am 20.06.2022 um 13:33 in 
>>> Nachricht
<20220620113345.5262.56...@hypatia.openldap.org>:
> 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.

Ignoring the loadbalancer issues, I think you add a race condition when reading 
possibly older data from your consumers and maybe write them back where newer 
data may exist already (i.e.: providers). BTW: Is a modify operation a read, or 
is it a write?

Regards,
Ulrich

>  
> Regards,
> Nagamani Chinnapaiyan

Antw: [EXT] Empty error when configuring OpenLDAP

[Ulrich Windl]

>>> Cezary Drozak  schrieb am 16.06.2022 um 22:42 in 
>>> Nachricht
<3a3f4745-56fc-91c5-0f0e-2cce6a473...@drozak.net>:
> 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

I think you (or the instructions) are mixing conf-syntax with config-syntax.
IMHO olc* is config-syntax.
See "man slapd.conf" vs. "man slapd-config".

Regards,
Ulrich


> 
> 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 

Antw: [EXT] [OPENLDAP 2.4] problem with cacert.pem certificates and its operation with openldap

[Ulrich Windl]

 >>> fredd fredddo  schrieb am 15.06.2022 um 19:46 in
Nachricht
:
> Hello,
> 
> I have a problem understanding how cacert.pem works on openldap 2.4 under
> centos.
> 
> I have an extremely heterogeneous machine park (with openldap customers and
> other owners)
> 
> So I have 2 Certificates (CA and intermediate CA) self-signed with the
> MD5withRSA algorithm and the same 2 certificates self-signed with the
> SHA1withRSA algorithm.

I don't know what clients you are using, but out certificate from 2018 uses 
sha256WithRSAEncryption.
It's likely that current clients don't accept weak certificates like MD5-based.

> 
> The 4 certificates are therefore in the cacert.pem of the server and the
> clients. (keystore)
> 
> It works perfectly for old servers but for new ones I have to force the use
> of TLS 1.1 because of the algorithms.
> 
> I have two problems:
> 
> If I just paste the 2 certificates in MD5 in the client keystore, it works,
> but if I leave the 2 certificates in SHA1, it does not work (bad
> certificate).  I don't understand how openldap reads the file when there
> are multiple choices . He starts with the first couple, if that doesn't
> work he goes to the next one?

If the client trusts the CA things should work "automagically".

> 
> So the idea would be to generate 2 new certificates identical to the others
> but with a SHA254 signature for example to work in TLS 1.2/1.3 and keep
> ldap compatibility with old servers.

How old is "old"?

> 
> The cacert.pem file of the OpenLDAP server would therefore have 6
> certificates and the clients following their OS would have the appropriate
> pair of certificates. Could this work? or for clients I leave the cacert
> the same and it will choose what it needs to establish the TLS connection?

Why would you use more than one certificate at all?

> 
>  I am a little lost ...
> 
> best regards
> Fred,

Antw: [EXT] RE: context of slapd service

[Ulrich Windl]

>>> "Bliss, Aaron"  schrieb am 14.06.2022 um 17:03 in
Nachricht


> Carsten,
> As a best practice whenever possible services in general should be ran 
> within the context of a user that has the least amount of privilege
possible. 
>  In this case, it's entirely supported and straightforward to configure 
> OpenLDAP to run as a non-privileged user and group and to further deploy 
> additional hardening on the user object such as setting the shell for that 
> user to /sbin/nologin, !! in /etc/shadow for the password field, etc.  I.E.

> systemd has long supported running services as a non-root user and again so

> do modern versions of Symas OpenLDAP:
> 
> https://repo.symas.com/soldap/systemd/ 
> 
> In a sense I would think that most enterprises would need to justify as to 
> why they wouldn't deploy OpenLDAP with the service configured to use a 
> non-privileged account.

Maybe I should mention one pitfall: When using slapadd to create databases,
better ran it as the user than runs slapd; otherwise they are owned by root,
most likely ;-)

> 
> Best,
> Aaron  
> 
> -Original Message-
> From: Carsten Jäckel  
> Sent: Monday, June 13, 2022 9:15 AM
> To: openldap-technical@openldap.org 
> Subject: context of slapd service
> 
> 
> Warning: This email is from outside the company. Be careful clicking links 
> or attachments.
> 
> Hello experts,
> 
> can you please give me some hints about best practice to run the slapd 
> service?
> Is it advantageous to run the slapd with it's own service user/group (e. g.

> ldap:ldap) or is it recommended to run slapd as root (as it seems to be 
> default)?
> Can you tell me something about advantages/disadvantages of each 
> configuration?
> 
> Thank you for your support,
> 
> Carsten
> 
> --
> The information contained in this message may be privileged, confidential 
> and protected from disclosure. If the reader of this message is not the 
> intended recipient, or an employee or agent responsible for delivering this

> message to the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this communication is strictly 
> prohibited. If you have received this communication in error, please notify

> your representative immediately and delete this message from your computer.

> Thank you.

Antw: [EXT] RE: Failing to modify olcSizeLimit

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 08.06.2022 um 18:03
in
Nachricht <1AA0097E3E4235DC5675E461@[192.168.1.17]>:

> discover that password.  I'd also advise them to change it, since you 
> publicly shared the SHA‑1 hash with the world.  I'd also advise them to use


Ignoring weak passwords, what are realistic brute-force attack times on SSHA
today?
I also wonder whether trying brute-force is worth it as the poster could have
swapped one or two characters in the BASE64 encpoding before sending ;-)

> a more secure hashing function (At least SSHA512, or even better upgrade to

> a currently supported release of OpenLDAP and use ARGON2).

Personally I think weak passwords (or the handling of such) is much more of a
security problem as SSH is.
However from the standpoint of admin, you are better off to use a strong
hashing function as it allows you to argue:
It must be the user's fault if the password became available...

Regards,
Ulrich

RE: Antw: [EXT] Failing to modify olcSizeLimit

[Ulrich Windl]

>>> RAIMBAULT Alain - Contractor 
schrieb
am 08.06.2022 um 12:47 in Nachricht
:
> Thanks for pointing at this element.
> I modified my ldif in consequence
> 
> # cat sizelimit.ldif
> dn: cn=config
> changetype: modify
> replace: olcSizeLimit
> olcSizeLimit: unlimited
> 
> root@ccase03 # grep olcRoot olcDatabase={1}mdb.ldif
> olcRootDN: cn=Manager,dc=tosa,dc=thales
> olcRootPW:: e1NTSEF9QTVnK3BPV2dWM2p6V29DZkRrSjVZZ1YwUDROS2RDTWg=
> ^ strange ! two semicolons in a row

First they are two _colons_, and second the LDIF specification says the data
is encodes as BASE64, usually because of "unusual" characters:
"{SSHA}A5g+pOWgV3jzWoCfDkJ5YgV0P4NKdCMh"

> 
> root@laselainfldap01p:/etc/openldap/slapd.d/cn=config# ldapmodify -v -h 
> 10.136.16.197 -D "cn=Manager,dc=tosa,dc=thales" -w tco_tosa_thales -f 
> sizelimit.ldif
> ldap_initialize( ldap://10.136.16.197 )
> replace olcSizeLimit:
> unlimited
> modifying entry "cn=config"
> ldap_modify: Insufficient access (50)

That was expected; does you manager have access?

> 
> root@laselainfldap01p:/etc/openldap/slapd.d/cn=config#
> 
> Kind regards,
> Alain
> 
> -Message d'origine-
> De : Ulrich Windl  
> Envoyé : mardi 7 juin 2022 07:48
> À : RAIMBAULT Alain - Contractor ;

> openldap-technical@openldap.org 
> Objet : Antw: [EXT] Failing to modify olcSizeLimit
> 
>>>> RAIMBAULT Alain - Contractor 
>>>> 
> schrieb
> am 03.06.2022 um 14:51 in Nachricht
> :
> ...
>> # cat sizelimit.ldif
>> dn: cn=config
>> changetype: modify
>> replace: olcSizeLimit
>> olcSizeLimit: ‑1
> 
> Despite of the rest we use a large positive number here, and the docs here 
> mention "unlimited", but not -1.
> 
> ...
> 
> Regards,
> Ulrich

Antw: [EXT] Failing to modify olcSizeLimit

[Ulrich Windl]

>>> RAIMBAULT Alain - Contractor 
schrieb
am 03.06.2022 um 14:51 in Nachricht
:
...
> # cat sizelimit.ldif
> dn: cn=config
> changetype: modify
> replace: olcSizeLimit
> olcSizeLimit: ‑1

Despite of the rest we use a large positive number here, and the docs here
mention "unlimited", but not -1.

...

Regards,
Ulrich

Antw: [EXT] Re: dynlist +memberOf loses casing in memberOf attribute

[Ulrich Windl]

>>> Michael Ströder  schrieb am 05.06.2022 um 23:16 in
Nachricht <51b7e769-522d-a547-4b4e-637e9d035...@stroeder.com>:
> On 6/5/22 23:02, Felix Schäfer wrote:
>>> Am 05.06.2022 um 22:36 schrieb Michael Ströder :
>>>
>>> But, like it or not, POSIX names are case-sensitive. So with
>>> posixGroup entries you have to preserve the case for completely
>>> consistent data. >
>> It’s not just posix.
> 
> Believe me I'm aware of all those issues.
> 
> That's the reason why my Æ-DIR mandates lower-cased user and group names.

Ah that bug: In the past we could lock out a user by entering it's name in
capitals (the user couldn't log in even with the correct password, as LDAP did
find the user).
Later the lower-case variant of the user would be locked out as well.

> 
> Ciao, Michael.

Re: Antw: [EXT] Re: dynlist +memberOf loses casing in memberOf attribute

[Ulrich Windl]

>>> Michael Ströder  schrieb am 07.06.2022 um 08:27 in
Nachricht <7ea49afd-d5f1-b7dc-e41a-709e523fd...@stroeder.com>:
> On 6/7/22 08:25, Ulrich Windl wrote:
>>>>> Michael Ströder  schrieb am 05.06.2022 um 23:16
in
>> Nachricht <51b7e769-522d-a547-4b4e-637e9d035...@stroeder.com>:
>>> On 6/5/22 23:02, Felix Schäfer wrote:
>>>>> Am 05.06.2022 um 22:36 schrieb Michael Ströder :
>>>>>
>>>>> But, like it or not, POSIX names are case-sensitive. So with
>>>>> posixGroup entries you have to preserve the case for completely
>>>>> consistent data. >
>>>> It’s not just posix.
>>>
>>> Believe me I'm aware of all those issues.
>>>
>>> That's the reason why my Æ-DIR mandates lower-cased user and group names.
>> 
>> Ah that bug: In the past we could lock out a user by entering it's name in
>> capitals (the user couldn't log in even with the correct password, as LDAP

> did
>> find the user).
>> Later the lower-case variant of the user would be locked out as well.
> 
> Hmm, which component enforced the lock out in this case?

It's quite some time ago; I can hardly remember.
I searched and found it. Seems to be a different problem, but now that you
were asking, I'm explaining:
For NIS compatibility were were uing ent´tries like this at the end of the
password file:
+@dialog_users:: 
+:NO-LOGIN:/sbin/nologin 

So all non-dialog users were denied login.
When I had eneterd the user in capital letters the NO-LOGIN entry matched,
but when entering the name correctly later, I could not log in.
I had found out that "getent passwd user" would show /sbin/nologin as shell
then.

In that case the solution was: "nscd -i passwd" (invalidate the password
cache)

So a different problem it seems, and sorry for the confusion.

Regards,
Ulrich


> 
> Ciao, Michael.

Re: Antw: [EXT] Re: dynlist vs memberof performance issues

[Ulrich Windl]

>>> Howard Chu  schrieb am 23.05.2022 um 18:04 in Nachricht
:
> Ulrich Windl wrote:
>>>>> "Paul B. Henson"  schrieb am 22.05.2022 um 04:51 in 
>>>>> Nachricht
>> <5d343067-aef3-b499-63e3-996f3d680...@acm.org>:
>>> On 5/11/2022 3:48 AM, Soisik Froger wrote:
>>>
>>>> Are this performance issues an expected side-effect of switching to 
>>>> dynlist - as the memberOf attributes are now dynamically calculated 
>>>> while the memberOf overlay used to writes these attributes - or 
>>>
>>> I am also having ongoing sporadic issues with memberOf performance using 
>>> the new dynlist overlay. Initially, randomly a server would get into a 
>>> state where any query requesting the memberOf attribute would take in 
>>> excess of 30 seconds, whereas normally it would only take a fraction of 
>>> a second. The symptoms were the same, free memory, no swapping, but 
>>> insanely high read IO load.
>> 
>> I'm wondering: If you'd make a core dump when the issue happens, how big 
> would such a core dump be with MDB?
>> I'm afraid it would be insanely large, containing the whole database. Am I 
> wrong?
> 
> Yes, you are wrong.
> 
> mmap'd memory isn't included in core dumps by default.

OK, but that makes it hard to debug any MDB issues from the core dump unless 
significant parts are copied in to private memory (which I think is not the 
idea behind MDB).

> 
> -- 
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com 
>   Director, Highland Sun http://highlandsun.com/hyc/ 
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/ 

Antw: [EXT] Re: dynlist vs memberof performance issues

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 22.05.2022 um 04:51 in 
>>> Nachricht
<5d343067-aef3-b499-63e3-996f3d680...@acm.org>:
> On 5/11/2022 3:48 AM, Soisik Froger wrote:
> 
>> Are this performance issues an expected side-effect of switching to 
>> dynlist - as the memberOf attributes are now dynamically calculated 
>> while the memberOf overlay used to writes these attributes - or 
> 
> I am also having ongoing sporadic issues with memberOf performance using 
> the new dynlist overlay. Initially, randomly a server would get into a 
> state where any query requesting the memberOf attribute would take in 
> excess of 30 seconds, whereas normally it would only take a fraction of 
> a second. The symptoms were the same, free memory, no swapping, but 
> insanely high read IO load.

I'm wondering: If you'd make a core dump when the issue happens, how big would 
such a core dump be with MDB?
I'm afraid it would be insanely large, containing the whole database. Am I 
wrong?

> 
> I cranked up the memory, which not did resolve the issue, but did help, 
> it doesn't happen nearly as often. But still, every now and again, a 
> server demonstrates a high read IO rate and severely degraded memberOf 
> query performance. At this point, I just have a monitoring check that 
> alerts on slow query performance and high read I/O and go restart them 
> when it happens, as the additional memory made the issue go from a 
> couple of times a week to every month or three.
> 
> I did notice now that when the issue occurs the box with the slow 
> queries does have less memory available then when it is working 
> normally, but still a good gigabyte of free memory not being used.
> 
> Even when the systems don't completely blow up, there are occasional 
> slower than normal queries. Typically the test query I am doing 
> literally takes fractions of a second:
> 
> May 21 19:47:22 ldap-01 slapd[1223]: conn=849157 op=1 SEARCH RESULT 
> tag=101 err=0 qtime=0.15 etime=0.198042 nentries=1 text=
> 
> Every now and again for no discernible reason it might take 5 to 10 seconds.

Antw: [EXT] Re: How to allow openldap searches for all just one group

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 30.04.2022 um 00:54
in
Nachricht <28499A685B1FAE689838078F@[192.168.1.17]>:

> 
> ‑‑On Friday, April 29, 2022 10:42 PM + gerson.gar...@itron.com wrote:
> 
>> Quanah,
>>
>> Yes I read it and tried replace "by * read" by "by * auth" and "by *
>> none" but then nobody could access it. Like I said, I am new on this, any
>> support other than google it, I would appreciate it.
> 
> olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * 
> none

Is there any security implication if one uses ".. by self write by * auth"
instead?

> olcAccess: {1}to attrs=shadowLastChange by self write by * read
> olcAccess: {2}to dn.subtree="dc=nocinbox,dc=inc" by 
> set="[cn=sec‑admin,ou=groups,dc=nocinbox,dc=inc]/memberUid & user/uid" 
> write by * read
> 
> 
> 
> The only thing that requires anonymous auth access is the userPassword 
> attribute.  However, other permissions may be necessary depending on the 
> operations.  It's important as well to understand the section on the pseudo

> attribute "entry too.
> 
> ‑‑Quanah

Re: Antw: [EXT] slapd (Symas 2.6.1) does not start with syncprov

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 27.04.2022 um 17:06
in
Nachricht <979B8C9BF3027ACA9450E58E@[192.168.1.20]>:

> 
> --On Wednesday, April 27, 2022 9:41 AM +0200 Ulrich Windl 
>  wrote:
> 
> 
>>> 0).
>>> Apr 26 18:31:27 apollo11 systemd‑coredump[1381]: Resource limits
>>> disable
>> core
>>> dumping for process 1377 (slapd).
>>
>> So maybe enable core dumps and show the backtrace.
> 
> Yep, assuming it's not an issue with the VM software being used, this would

> be the next general step.  I would note that installing the relevant debug 
> symbol packages for slapd will be necessary as well.
> 
> It may be needed to attach to the slapd process with GDB prior to running 
> the syncprov change as well, since core dumps often lose useful information

> that the running process has.

In case you test your own software, non-optimized builds can be really
helpful, specifically as gcc inlines functions massively at -O2 and higher
(older versions did not).

> 
> --Quanah

Antw: [EXT] slapd (Symas 2.6.1) does not start with syncprov

[Ulrich Windl]

>>> Magnus Morén  schrieb am 26.04.2022 um 19:56 in
Nachricht


> Migrating to new ldap server and getting problems.
> 
> OS:   Rocky Linux 8 (== RHEL/CentOS 8). Fully updated.
> LDAP software:   symas‑openldap‑servers‑2.6.1‑2.el8.x86_64
> 
> 
> cn=config and and data import (via ldif) on master. Everything look good. 
> start/stop/restart is working. ldap access is working.
> 
> Adding "syncprov" on master (to enable producer/consumer mode). Now the 
> slapd on the master/producer crashes on start!
> 
> 
> Apr 26 18:31:27 apollo11 systemd[1]: Started Symas OpenLDAP Server Daemon.
> Apr 26 18:31:27 apollo11 kernel: traps: slapd[1379] general protection fault

> ip:7fa53a499f38 sp:7fa4f8e3d1b0 error:0 in 
> back_mdb.so.2.0.200[7fa53a471000+4]
> Apr 26 18:31:27 apollo11 systemd[1]: Started Process Core Dump (PID 1380/UID

> 0).
> Apr 26 18:31:27 apollo11 systemd‑coredump[1381]: Resource limits disable
core 
> dumping for process 1377 (slapd).

So maybe enable core dumps and show the backtrace.

> Apr 26 18:31:27 apollo11 systemd‑coredump[1381]: Process 1377 (slapd) of
user 
> 0 dumped core.
> Apr 26 18:31:27 apollo11 systemd[1]: symas‑openldap‑servers.service: Main 
> process exited, code=killed, status=11/SEGV
> Apr 26 18:31:27 apollo11 systemd[1]: symas‑openldap‑servers.service: Failed

> with result 'signal'.
> Apr 26 18:31:27 apollo11 systemd[1]: systemd‑coredump@3‑1380‑0.service: 
> Succeeded.
> 
> 
> The syncprov ldif
> 
> 
> dn: cn=module{0},cn=config
> changetype: modify
> add: olcModuleLoad
> olcModuleLoad: syncprov.la
> 
> dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
> olcSpCheckpoint: 100 10
> olcSpSessionlog: 100
> 
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> add: olcDbIndex
> olcDbIndex: entryCSN,entryUUID eq
> 
> 
> Magnus Morén

Re: Antw: [EXT] Re: STARTTLS vs LDAPS

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 31.03.2022 um 17:45
in
Nachricht :

> 
> ‑‑On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl 
>  wrote:
> 
>> I think the point was that you can bind even when not having started TLS
>> before.
> 
> Correct.
> 
>> I don't know whether this can prevent it:
>> olcSecurity: ssf=0 update_ssf=128 simple_bind=64
> 
> There is no way to prevent a client from sending a BIND request to an 
> ldap:/// URI with the DN and password in the clear.  Even if you set ssf=1 
> (server mandates encryption), the most that will happen is that the client 
> will get disconnected, but the DN and password will already have traveled 
> over the network in the clear before the client gets disconnected so anyone

> sniffing the traffic would have access to it.

But honestly, you could get the same when setting up SSL incorrectly (using
eNULL or RSA-PSK-NULL-SHA).
Also I think if you require an anonymous bind first, the SSF may prevent
sending actual user passwords unencrypted; right?

Regards,
Ulrich

> 
> ‑‑Quanah

Re: Antw: [EXT] Re: RE26 testing call #1 (OpenLDAP 2.6.2)

[Ulrich Windl]

>>> Ondrej Kuzník  schrieb am 01.04.2022 um 11:23 in
Nachricht
<20220401092310.ge26...@mistotebe.net>:
> On Fri, Apr 01, 2022 at 11:03:43AM +0200, Ulrich Windl wrote:
>>> On Wed, Mar 23, 2022 at 03:07:25PM +0100, Michael Ströder wrote:
>>>> Do you have any particular things in mind that need more thorough
testing
>>>> before 2.6.2 is released?
>>> 
>>> It was a general question. While it's nice that people run "make test"
and
>>> sometimes "make its", it would be even nicer if we got regular feedback
>>> from actual test environments. If we got people to publish any metrics
>>> they gather (performance or otherwise), we could even track the
>>> evolution of the software in a real world setting, I know I'm not asking
>>> for much ;)
>> 
>> Maybe maintain an OVL for each release, where "OVL" means "Operating
System
>> Verification List" ;-)
>> (The list of Operating System Releases where compilation and selftest
>> succeeded)
> 
> I don't think that's too helpful, since getting people to run OpenLDAP's
> own self-tests has never been a problem in my view. It's running
> the software with a real-world configuration that never seems to get
> reported.
> 
> I know Shawn runs a few replication scenarios regularly. It would be
> nice to know if we could get others to consider running the release
> candidates in their own test or staging systems and what were the
> perceived issues to getting that going.

I was thinking like "Qubes OS HCL" (Hardware Compatibility List) that is
viewable on their website.
Of course if your statement is "our software runs everywhere without any
problems", then you don't need it ;-)

Regards,
Ulrich

> 
> Regards,
> 
> -- 
> Ondřej Kuzník
> Senior Software Engineer
> Symas Corporation   http://www.symas.com 
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP

Antw: [EXT] Re: RE26 testing call #1 (OpenLDAP 2.6.2)

[Ulrich Windl]

>>> Ondrej Kuzník  schrieb am 31.03.2022 um 17:55 in
Nachricht
<2022033118.gd26...@mistotebe.net>:
> On Wed, Mar 23, 2022 at 03:07:25PM +0100, Michael Ströder wrote:
>> On 3/23/22 12:19, Ondřej Kuzník wrote:
>>> On Tue, Mar 22, 2022 at 08:03:35PM +0100, Michael Ströder wrote:
>>> > On 3/22/22 18:21, Quanah Gibson-Mount wrote:
>>> > > This is the first testing call for OpenLDAP 2.6.2.
>>> > 
>>> > Tested git revision 475e57281bc10e56a47021895a7b926e29ac9072 on
openSUSE
>>> > Tumbleweed x64_64 (gcc version 11.2.1):
>>> > 
>>> > - make test worked
>>> > - unit tests of my Python module ldap0 work
>>> Just a thought, are people pushing the RC code into testing/pre-prod
>>> environments?
>> 
>> Sometimes I do on my openSUSE-based Æ-DIR test systems based on branches
of
>> my packages in OBS. But it's additional work for which I don't always have
>> spare time left.
> 
> Hi Michael,
> thanks, even that's appreciated.
> 
>> Do you have any particular things in mind that need more thorough testing
>> before 2.6.2 is released?
> 
> It was a general question. While it's nice that people run "make test" and
> sometimes "make its", it would be even nicer if we got regular feedback
> from actual test environments. If we got people to publish any metrics
> they gather (performance or otherwise), we could even track the
> evolution of the software in a real world setting, I know I'm not asking
> for much ;)

Maybe maintain an OVL for each release, where "OVL" means "Operating System
Verification List" ;-)
(The list of Operating System Releases where compilation and selftest
succeeded)

> 
>>> Does the current schedule of 1+ weeks between a testing
>>> call and potential release give you enough time?
>> 
>> IMHO most people are not going to test in real environments before the
>> OpenLDAP project cuts a release, no matter how long this testing period
is.
> 
> That has been a hypothesis for a while and this is an attempt to
> challenge it, just in case :)
> 
> Thanks,
> 
> -- 
> Ondřej Kuzník
> Senior Software Engineer
> Symas Corporation   http://www.symas.com 
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP

Antw: [EXT] Re: STARTTLS vs LDAPS

[Ulrich Windl]

>>>  schrieb am 31.03.2022 um 06:29 in 
>>> Nachricht
<20220331042904.5262.30...@hypatia.openldap.org>:
> Quanah Gibson-Mount wrote:
>> --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania 
>> > 
>> >  That's what can be found in the FAQ on openldap.org:
>> > 
>> >  https://www.openldap.org/faq/data/cache/605.html 
>> > 
>> >  I would trust this more then any rumors on any stack page ;) 
>> Unfortunately, the FAQ is dead weight we want to kill and not maintained in 
>> any way, shape, or form.  It's currently provided for historical purposes.
>> 
>> As to this overall discussion, one of the primary issues with connections 
>> over ldap:/// is that there's zero way with simple binds to prevent the 
>> bind dn + password being sent in the clear by a client to the server.  With 
>> ldaps:/// the encryption is set up before the BIND occurs so you don't run 
>> this risk.
> 
> Is that true? Surely I can 
> 1. connect to the server
> 2. Send starttls
> 3. Then bind bind can't I? 
> I'm fairly certain I've used LDAP Client operating in that order.

I think the point was that you can bind even when not having started TLS before.

I don't know whether this can prevent it:
olcSecurity: ssf=0 update_ssf=128 simple_bind=64

(I can't remember why I put "ssf=0" there; maybe to allow anonymous DLAPv2)

Regards,
Ulrich

> 
>> 
>> So from that standpoint, I'd personally prefer to see ldaps:/// qualified 
>> in an RFC so the standardization argument goes away and ldaps be noted as 
>> the preferred method for sites that require encryption.
> 
> I agree there is no technical reason LDAPS would not be better. It should be 
> made standard.

Antw: [EXT] Re: STARTTLS vs LDAPS

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 30.03.2022 um 19:54
in
Nachricht :

> 
> ‑‑On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania 
>  wrote:
> 
>> That's what can be found in the FAQ on openldap.org:
>>
>> https://www.openldap.org/faq/data/cache/605.html 
>>
>> I would trust this more then any rumors on any stack page ;)
> 
> Unfortunately, the FAQ is dead weight we want to kill and not maintained in

> any way, shape, or form.  It's currently provided for historical purposes.
> 
> As to this overall discussion, one of the primary issues with connections 
> over ldap:/// is that there's zero way with simple binds to prevent the 
> bind dn + password being sent in the clear by a client to the server.  With

> ldaps:/// the encryption is set up before the BIND occurs so you don't run 
> this risk.
> 
> So from that standpoint, I'd personally prefer to see ldaps:/// qualified 
> in an RFC so the standardization argument goes away and ldaps be noted as 
> the preferred method for sites that require encryption.

So while talking about FAQs, maybe someone add:
"How to convert am OpenLDAP STARTLTS configuration to ldaps://?"

> 
> ‑‑Quanah

Re: Antw: [EXT] creatorsname not correctly updated

[Ulrich Windl]

>>> Jean-Luc Bourguignon  schrieb am 09.03.2022 um 13:02
in
Nachricht :
> Hello Ulrich,
> 
> I’ve to correct the information I gave at start of the tread. After 
> investigation and some corrections on the 2MMR env, both environment gave me

> same result now. 
> 
> In fact, I’ve proxy configuration on this replication user which works fine

> for a normal user that add entries in the DB, creatosname is its name, but 
> when I use the rootdn user, it’s the replication user is stored in 
> creatorsname. I’ve added another rule authzTo rule in the replication user 
> for the rootdn user but it doesn’t help to get entries created by him with 
> his name in creatorsname attribut. 

Hi!

Here I have "olcAccess: {0}to * by
dn.exact="uid=syncrepl,ou=system,dc=...,dc=de" read ..." for the syncrepl user
(no proxying).
Out of curiosity: Is only the creatorsName different, but also the
CreationTime?
Also If the objects are not re-created and you use deltasyncrepl, the
creatorsName probably wouldn't be updated until the objects is actually created
new (meaning: It won't fix existing inconsistencies)

What about modifiersName and modifyTimestamp?

Regards,
Ulrich


> 
> Brgds,
> Jean-Luc 
> 
> On 9 Mar 2022, at 09:33, Ulrich Windl  
> wrote:
> 
>>>>>  schrieb am 08.03.2022 um 17:43 in Nachricht
>> <20220308164344.5262.14...@hypatia.openldap.org>:
>>> Dears,
>>> 
>>> I've a tricky issue with this attribute.
>>> I context of 4 MMR & 4 replicas, I've defined a rootdn and a replication 
>>> user. When I create "ADD" a new entry in my DB with rootdn as user, the 
>>> creatorsname is filled up with the replication username instead of rootdn

> one 
>>> :-|
>> 
>> Are you sure your replication user can read all attributes?
>> 
>>> I've another configuration with 2 MMR & 2 replicas, normally same config
as 
>>> above, but there, the ADD is correctly managed.
>>> In both configuration, replicas send their ADD request to masters VIP with

>>> olcUpdateRef attribut. and received update via masters VIP with
olcSyncrepl 
>>> attribut. 
>>> 
>>> Any idea of any parameter, acl, schema to check ?
>>> 
>>> Thx,
>>> J-L.
>> 
>> 
>> 
>> 

Antw: [EXT] creatorsname not correctly updated

[Ulrich Windl]

>>>  schrieb am 08.03.2022 um 17:43 in Nachricht
<20220308164344.5262.14...@hypatia.openldap.org>:
> Dears,
> 
> I've a tricky issue with this attribute.
> I context of 4 MMR & 4 replicas, I've defined a rootdn and a replication 
> user. When I create "ADD" a new entry in my DB with rootdn as user, the 
> creatorsname is filled up with the replication username instead of rootdn one 
> :-|

Are you sure your replication user can read all attributes?

> I've another configuration with 2 MMR & 2 replicas, normally same config as 
> above, but there, the ADD is correctly managed.
> In both configuration, replicas send their ADD request to masters VIP with 
> olcUpdateRef attribut. and received update via masters VIP with olcSyncrepl 
> attribut. 
> 
> Any idea of any parameter, acl, schema to check ?
> 
> Thx,
> J-L.

Re: Antw: [EXT] Re: Finding the userPassword schema

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 28.02.2022 um 18:13
in
Nachricht :

> 
> ‑‑On Monday, February 28, 2022 8:01 AM +0100 Ulrich Windl 
>  wrote:
> 
>> ldapsearch ‑Y EXTERNAL ‑H ldapi:/// ‑b 'cn=Subschema' ‑s base
>> '(olcSchemaConfig=*)' 'attributeTypes'
> 
> olcSchemaConfig is not a valid objectClass to filter on for cn=subschema

Yes, I know many ways how _not_ to do it; insted I was hoping the other way
'round ;-)

> 
> ‑‑Quanah

Antw: [EXT] Re: Finding the userPassword schema

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 24.02.2022 um 16:41
in
Nachricht <5634EEEFC927B18BF1B59D49@[192.168.1.12]>:

> 
> ‑‑On Thursday, February 24, 2022 8:22 AM +0100 Ulrich Windl 
>  wrote:
> 
>> So my guess is that my query is still wrong:
>># ldapsearch ‑Y EXTERNAL ‑H ldapi:/// ‑b 'cn=Subschema' ‑s sub
>> '(objectClass=*)' '* +'
> 
> Why did you use ‑s sub? I clearly used ‑s base in my example I provided
you.
> 
> Additionally, '* +' is invalid.  It should be:
> 
> '*' '+'

OK, I thought ("<=" meaning subset relation) that "base <= one <= sub", but it
seems "base < one <= sub" instead.
And I mixed up the syntax for attributes as well.

So I found userPassword, but I had to use a vcombination of ldapsearch and
grep like this:
ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s base
'(attributeTypes=*)' '+' |grep userPassword

What I don't understand is that for

ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s base
'(olcSchemaConfig=*)' 'attributeTypes'

I get no results:

# search result
search: 2
result: 0 Success

Is there a filter to get the definition for userPassword specifically?

Regards,
Ulrich


> 
> ‑‑Quanah

Re: Antw: [EXT] Re: Password policies and hashed passwords

[Ulrich Windl]

>>> Felix Natter  schrieb am 23.02.2022 um 21:45 in Nachricht
<87wnhl9uru@bitburger.home.felix>:
> hello Ulrich,
> 
> thanks for your reply! My replies are inline:
> 
> "Ulrich Windl"  writes:
>>>>> Felix Natter  schrieb am 22.02.2022 um 19:00 in Nachr=
> icht
>> <87h78qlr1i@bitburger.home.felix>:
>>> hello Michael,
>>>=20
>>> many thanks for your reply!
>>>=20
>>> Michael Str=C3=B6der  writes:
>>>> On 2/20/22 18:14, Felix Natter wrote:
>>>>> my password policies (openldap 2.5.11) are not enforced and Roland
>>>>> Gruber (author of LAM (Pro)) kindly advised me that passwords must be
>>>>> stored in plaintext (Hash=3DPLAIN) in order to be able to enforce pass=
> word
>>>>> minimal length, password quality etc (i.e. when using passwd(1) on Lin=
> ux
>>>>> or an LDAP client on Windows).
>>>>
>>>> Nope. That sounds like misleading advice, or it's a misunderstanding on
>>>> your side.
>>>>
>>>> 1. The LDAP client should support setting new password via LDAP Modify
>>>> Password extended operation
>>>=20
>>> I tried with passwd(1), which currently ignores the ppolicy. Does this
>>> mean it does not support an LDAP Modify Password *extended* operation?
>>> If not, can I enable it?
>>
>> I have these lines in /etc/ldap.conf (and it works):
>> # Search the root DSE for the password policy (works
>> # with Netscape Directory Server). Make use of
>> # Password Policy LDAP Control (as in OpenLDAP)
>> pam_lookup_policy   yes
>> ...
>> # Use the OpenLDAP password change
>> # extended operation to update the password.
>> pam_passwordexop
>> ...
> 
> This is on the client, right?

Yes!

> 
> I tried putting the two above options in /etc/openldap/ldap.conf,
> rebooted, but no change. Also man ldap.conf does not mention them.


As the "pam_" prefix might indicate, try "man pam_ldap" instead.

...
   Features  of  the  PADL  pam_ldap  module include support for transport
   layer security, SASL authentication, directory server-enforced password
   policy, and host- and group- based logon authorization.
...
   pam_lookup_policy 
  Specifies whether to search the root DSE  for  password  policy.
  The default is "no".
...

> 
> Which OS do you use?

SLES 12 SP5

I also have:
# grep ldap /etc/nsswitch.conf
group:  files ldap
services:   files ldap
netgroup:   files ldap
aliases:files ldap
passwd_compat:  ldap

and

/etc/pam.d # cat login
#%PAM-1.0
auth requisite  pam_nologin.so
auth [user_unknown=ignore success=ok ignore=ignore auth_err=die 
default=bad]pam_securetty.so
auth includecommon-auth
account  includecommon-account
password includecommon-password
session  required   pam_loginuid.so
session  includecommon-session
session  optional   pam_lastlog.so  nowtmp
session  optional   pam_mail.so standard

Maybe this helps.

Regards,
Ulrich

> 
> I can find a file with this syntax on Redhat6: /etc/pam_ldap.conf.
> On Redhat7 (my case), it seems to have been replaced with
> /etc/nslcd.conf (different syntax) where I could only find this option:
> 
> pam_authc_ppolicy yes|no
> "This option specifies whether password policy controls are
> requested and handled from the LDAP server when performing
> user authentication"
> 
> Could the password modify extended operation be enabled by default (on
> Redhat7) and the problem lies elsewhere?
> 
> This is supported by the following test with ldappasswd:
> 
> ldappasswd -H ldap:// -x -D \
> cn=3Dldaptestuser1,ou=3Dusers,dc=3Dcompany,dc=3Dcom -W -A -S
> 
> also bypasses the policy's minimal length restriction (pwdMinLength: 3;
> that is the only PPolicy field that is defined)
> 
> According to the man page, this "uses the LDAPv3 Password Modify (RFC
> 3062) extended operation". Does this mean that password policies are not
> correctly set up on the server? How can I debug this?
> 
> Many Thanks and Best Regards,
> Felix Natter
> 
>>>=20
>>>> or
>>>>
>>>> 2. as you already found out yourself you can use
>>>>
>>>>  olcPPolicyHashCleartext: TRUE
>>>>
>>>> if the LDAP client sends a MODIFY operation with a clear-text userPassw=
> ord
>>>> value.
>>>>
>>>> Both options will let slapd hash the password according to the setting =
> of
>>>> password-hash (slapd.conf) / olc

Finding the userPassword schema

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 23.02.2022 um 17:46
in
Nachricht <930DB73AD6C9D8388B3A80F5@[192.168.1.12]>:

> 
> --On Wednesday, February 23, 2022 8:25 AM +0100 Ulrich Windl 
>  wrote:
> 
>>>>> Yes, if you query the right place.  I.e., cn=subschema:
>>>>>
>>>>> ldapsearch ... ‑s base ‑b "cn=subschema" +
>>>>
>>>> When I try that I get "No such object", and when I try
>>>
>>> Then you used a bind identity that doesn't have access to cn=subschema.
>>> Generally it is advised that cn=subschema should be readable by anyone.
>>
>> I have this in "dn: olcDatabase={-1}frontend,cn=config":
>> olcAccess: {0}to dn.exact="" by * read
>> olcAccess: {1}to dn.base="cn=Subschema" by * read
>>
>> Shouldn't that do?
> 
> Generally yes, but your stated results would indicate otherwise.

I don't get it: The ACL is there, and the subschema seems to be there, but I
cannot find it.
In Perl the root_dse indicates:
...
 6  HASH(0x2d49578)
'type' => 'subschemaSubentry'
'vals' => ARRAY(0x2d49800)
   0  'cn=Subschema'
...

So it seems to be there. Likewise when I diesplay the "schema" entry I get:
  'userpassword' => HASH(0x2e483b0)
 'aliases' => ARRAY(0x2e48440)
  empty array
 'desc' => 'RFC4519/2307: password of user'
 'equality' => 'octetStringMatch'
 'max_length' => 128
 'name' => 'userPassword'
 'oid' => '2.5.4.35'
 'syntax' => '1.3.6.1.4.1.1466.115.121.1.40'
 'type' => 'at'

So my guess is that my query is still wrong:
# ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Subschema' -s sub
'(objectClass=*)' '* +'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectClass=*)
# requesting: * +
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
--


Regards,
Ulrich

Re: Antw: [EXT] Problem with ppolicy overlay and userPassword attribute

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 22.02.2022 um 17:49
in
Nachricht <6D8946CEFE1406A76522A36F@[192.168.1.12]>:

> 
> --On Tuesday, February 22, 2022 12:44 PM +0100 Ulrich Windl 
>  wrote:
> 
>>>>> Quanah Gibson-Mount  schrieb am 18.02.2022 um
>>>>> 22:37
>> in
>> Nachricht <8A1ED4C1E941394D45838C24@[192.168.1.12]>:
>>
>>>
>>> ‑‑On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl
>>>  wrote:
>>>
>>>> But I should be able to query it, right? If so what is the correct
>>>> filter expression?
>>>
>>>
>>> Yes, if you query the right place.  I.e., cn=subschema:
>>>
>>> ldapsearch ... ‑s base ‑b "cn=subschema" +
>>
>> When I try that I get "No such object", and when I try
> 
> Then you used a bind identity that doesn't have access to cn=subschema. 
> Generally it is advised that cn=subschema should be readable by anyone.

I have this in "dn: olcDatabase={-1}frontend,cn=config":
olcAccess: {0}to dn.exact="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read

Shouldn't that do?

> 
> --Quanah

Antw: [EXT] Re: Password policies and hashed passwords

[Ulrich Windl]

>>> Felix Natter  schrieb am 22.02.2022 um 19:00 in Nachricht
<87h78qlr1i@bitburger.home.felix>:
> hello Michael,
> 
> many thanks for your reply!
> 
> Michael Ströder  writes:
>> On 2/20/22 18:14, Felix Natter wrote:
>>> my password policies (openldap 2.5.11) are not enforced and Roland
>>> Gruber (author of LAM (Pro)) kindly advised me that passwords must be
>>> stored in plaintext (Hash=PLAIN) in order to be able to enforce password
>>> minimal length, password quality etc (i.e. when using passwd(1) on Linux
>>> or an LDAP client on Windows).
>>
>> Nope. That sounds like misleading advice, or it's a misunderstanding on
>> your side.
>>
>> 1. The LDAP client should support setting new password via LDAP Modify
>> Password extended operation
> 
> I tried with passwd(1), which currently ignores the ppolicy. Does this
> mean it does not support an LDAP Modify Password *extended* operation?
> If not, can I enable it?

I have these lines in /etc/ldap.conf (and it works):
# Search the root DSE for the password policy (works
# with Netscape Directory Server). Make use of
# Password Policy LDAP Control (as in OpenLDAP)
pam_lookup_policy   yes
...
# Use the OpenLDAP password change
# extended operation to update the password.
pam_passwordexop
...

> 
>> or
>>
>> 2. as you already found out yourself you can use
>>
>>  olcPPolicyHashCleartext: TRUE
>>
>> if the LDAP client sends a MODIFY operation with a clear-text userPassword
>> value.
>>
>> Both options will let slapd hash the password according to the setting of
>> password-hash (slapd.conf) / olcPasswordHash (cn=config).
> 
> Now I added olcPPolicyHashCleartext: TRUE to the ppolicy overlay:
> 
> dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
> changetype: modify
> add: olcPPolicyHashCleartext
> olcPPolicyHashCleartext: TRUE
> 
> sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f ppolicyoverlay2.ldif
> modifying entry "olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config"
> 
> It now looks like this:
> dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcPPolicyConfig
> olcOverlay: {0}ppolicy
> olcPPolicyDefault: cn=default,ou=policies,dc=sidact,dc=com
> structuralObjectClass: olcPPolicyConfig
> entryUUID: 
> creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> createTimestamp: 20220215121841Z
> olcPPolicyHashCleartext: TRUE
> entryCSN: 20220222113122.616521Z#00#000#00
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20220222113122Z
> 
> But still, the password policy is not enforced with passwd(1).
> 
>> Processing simple bind requests are not affected by these
>> settings. 
> 
> Bind request means login request, as opposed to password change request?
> 
>> Existing password hashes will not be altered.
> 
> Yes, I read that ppolicies only work if the password is changed or
> expires.
> 
> Could you please advise how to enforce the PP?
> 
>>> [3] The manual states "Unfortunately, as dictionary and brute force
>>> attacks are generally quite easy for attackers to successfully mount,
>>> this advantage is marginal at best (this is why all modern Unix systems
>>> use shadow password files)."
>>
>> Well, this all is debatable.
>>
>> 1. Implement decent ACLs which forbids any read access to all LDAP clients
>> (except replicas).
>>
>> 2. Choose a decent hash algorithm, especially understand the
>> parameters. Recent OpenLDAP support {ARGON2} out-of-the-box. Note that
>> choosing the right parameters is trading performance with security. ARGON2
>> is called "memory-hard" and you should take this literally.
>>
>> For inspiration read the comments and examples here:
>>
>> 
>
https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/main/defaul

> ts/main.yml#L712
> 
> Ok, thanks.
> 
> Many Thanks and Best Regards,
> Felix
> -- 
> Felix Natter

Re: Antw: [EXT] Problem with ppolicy overlay and userPassword attribute

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 18.02.2022 um 22:37
in
Nachricht <8A1ED4C1E941394D45838C24@[192.168.1.12]>:

> 
> ‑‑On Friday, February 18, 2022 9:03 AM +0100 Ulrich Windl 
>  wrote:
> 
>> But I should be able to query it, right? If so what is the correct filter
>> expression?
> 
> 
> Yes, if you query the right place.  I.e., cn=subschema:
> 
> ldapsearch ... ‑s base ‑b "cn=subschema" +

When I try that I get "No such object", and when I try "cn=schema,cn=config"
with "(olcAttributeTypes=*)" and "sub" I see
cn=schema,cn=config
cn={0}core,cn=schema,cn=config
cn={1}cosine,cn=schema,cn=config
...
cn={6}sudo,cn=schema,cn=config

but no userPassword anywhere.
That's why I was asking. Or is it available only recently?

However the string is in the binary:
# strings /usr/lib/openldap/slapd |grep userPass
( 2.5.4.35 NAME 'userPassword' DESC 'RFC4519/2307: password of user' EQUALITY
octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

Regards,
Ulrich

> 
> Regards,
> Quanah

Re: Antw: [EXT] Problem with ppolicy overlay and userPassword attribute

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 17.02.2022 um 18:19
in
Nachricht <49ADC11B5FB3A8060B8AC3C5@[192.168.1.12]>:

> 
> ‑‑On Thursday, February 17, 2022 11:20 AM +0100 Ulrich Windl 
>  wrote:
> 
>> Interestingly I found that userPassword is commented out in core.schema,
>> and the commented‑out entry does not have "single‑value".
>> Also I couldn't find it when querying cn=schema,cn=config on my server.
>> Is it "special"?
> 
> Yes, it's compiled into slapd.  see servers/slapd/schema_prep.c:
> 
> { "userPassword", "( 2.5.4.35 NAME 'userPassword' "
> "DESC 'RFC4519/2307: password of user' "
> "EQUALITY octetStringMatch "
> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )",

But I should be able to query it, right? If so what is the correct filter
expression?

Regards,
Ulrich

> 
> 
> ‑‑Quanah

Antw: [EXT] Problem with ppolicy overlay and userPassword attribute

[Ulrich Windl]

>>> Frederic Dussurget  schrieb am 16.02.2022
um
14:53 in Nachricht :
> Hi,
> We're facing the following issue :
> 
>   *   From one side, we have to store two values (same password with two 
> different encodings) within the userPassword attribute (eg. 
> https://datatracker.ietf.org/doc/html/rfc4519#section‑2.41)
>   *   On the other side, we do have to use the ppolicy overlay in order to 
> hash to Argon2 automatically passwords that are sent in cleartext, in order

> to to use the pwdLastSuccess attribute (storing last authentication date)
and 
> pwdAccountLockedTime  (account deactivation), but this overlay does not seem

> to support multiple values in the userPassword attribute as it looks to be 
> described in the following abstract : 
>
https://datatracker.ietf.org/doc/html/draft‑behera‑ldap‑password‑policy‑10#section‑

> 3 and 
> https://www.openldap.org/software/man.cgi?query=slapo‑ppolicy&sektion=5&apro

> pos=0&manpath=OpenLDAP+2.5‑Release
> 
> 
> 
> We're not able to add a user account with two values in the userPassword 
> attribute :
> [root@openldap25 ~]# cat testuser_add.ldif
> dn: uid=testuser,ou=people,dc=my‑domain,dc=fr
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: top
> uid: testuser
> cn: testuserCN
> sn: testuserSN
> userPassword: password
> userPassword: drowssap
> 

Interestingly I found that userPassword is commented out in core.schema, and
the commented-out entry does not have "single-value".
Also I couldn't find it when querying cn=schema,cn=config on my server.
Is it "special"?

> [root@openldap25 ~]# ldapadd ‑H ldaps://localhost:636 ‑x ‑D 
> "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑f testuser_add.ldif
> Enter LDAP Password:
> adding new entry "uid=testuser,ou=people,dc=my‑domain,dc=fr"
> ldap_add: Constraint violation (19)
> additional info: Password policy only allows one password value
> 
> 
> However, we're able to add a user with a single value in the userPassword 
> attribute, then, adding a second value thru the next LDAP request :
> 
> [root@openldap25 ~]# cat testuser_add.ldif
> dn: uid=testuser,ou=people,dc=my‑domain,dc=fr
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: top
> uid: testuser
> cn: testuserCN
> sn: testuserSN
> userPassword : password
> 
> [root@openldap25 ~]# ldapadd ‑H ldaps://localhost:636 ‑x ‑D 
> "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑f testuser_add.ldif
> Enter LDAP Password:
> adding new entry "uid=testuser,ou=people,dc=my‑domain,dc=fr"
> 
> [root@openldap25 ~]# cat testuser_mod.ldif
> dn: uid=testuser,ou=people,dc=my‑domain,dc=fr
> changetype: modify
> add: userPassword
> userPassword: drowssap
> 
> [root@openldap25 ~]# ldapmodify ‑H ldaps://localhost:636 ‑x ‑D 
> "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑f testuser_mod.ldif
> Enter LDAP Password:
> modifying entry "uid=testuser,ou=people,dc=my‑domain,dc=fr"
> 
> [root@openldap25 ~]# ldapsearch ‑x ‑H ldaps://localhost:636 ‑D 
> "cn=Manager,dc=my‑domain,dc=fr" ‑W ‑LLL ‑b "ou=people,dc=my‑domain,dc=fr" 
> "(uid=testuser)" userPassword
> Enter LDAP Password:
> dn: uid=testuser,ou=people,dc=my‑domain,dc=fr
> userPassword:: 
> e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkZjlPc3NtRFZ
>
DWmlzQk1IVEhWczRMZyRsMVAvbWdEdTA1bEpBc2pxcVF6aERYaENMV1BudnQyeDlRTDdweXFnVDF
> V
> userPassword:: 
> e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkVk5ST1FMZFp
>
2Q0ptajNIcHQxYWtZdyRRcjJDYUpKSjZSWlhvZjFicDJmNGNOaGlRa3E5czlCU0FTbEtVNFoxYjB
> j
> 
> Considering configuration, we're running an OpenLDAP 2.5.7 server (LTB 
> project) on a RHEL8 OS.
> 
>   *   ppolicy overlay
> dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcPPolicyConfig
> olcOverlay: {0}ppolicy
> olcPPolicyHashCleartext: TRUE
> olcPPolicyUseLockout: FALSE
> olcPPolicyForwardUpdates: FALSE
> olcPPolicyDisableWrite: FALSE
> olcPPolicySendNetscapeControls: FALSE
> olcPPolicyDefault: cn=default,ou=ppolicies,dc=my‑domain,dc=fr
> 
>   *   default password policy
> dn: ou=ppolicies,dc=my‑domain,dc=fr
> objectClass: organizationalUnit
> objectClass: top
> ou: ppolicies
> 
> dn: cn=default,ou=ppolicies,dc=my‑domain,dc=fr
> objectClass: pwdPolicy
> objectClass: organizationalRole
> cn: default
> pwdAttribute: userPassword
> pwdLockout: TRUE
> 
>   *   password storage
> dn: olcDatabase={‑1}frontend,cn=config
> olcPasswordHash: {ARGON2}
> 
> Question :
> 
> 
>   *   Is that behaviour normal ?
>   *   May we keep on leaning on this behaviour without fearing that this 
> ability of adding a second value to the userPassword attribute will be 
> revoked in the future versions/fix/patches of the service ?
> 
> 
> Thank you in advance for your assistance.
> 
> Best regards,
> 
> Frédéric Dussurget / Maxime Schmutz
> Université Lumière Lyon 2

Antw: [EXT] Re: slow memberOf queries in 2.5 with dynlist overlay

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 16.02.2022 um 04:10 in 
>>> Nachricht
<114ede97-a51b-5fbd-0613-47208945a...@acm.org>:

...
> I can certainly just throw memory at it and hope the problem goes away. 

Remember there are some classic tools like sar, vmstat, iostat, etc. to display 
or store some interesting information about what the OS is doing.
Maybe youngsters will prefer something like "watch cat /proc/meminfo" to see 
live how RAM is shuffled around.

> But based on the observations when it occurs it does not feel like just 
> a memory problem. The last time it happened I pulled the node out of the 
> load balancer so nothing else was poking at it and the test query was 
> still taking more than 30 seconds.

iotop is another nice utility.

> 
> I'm going to bump the production nodes up to 4G, which should be more 
> than enough to run the OS and always have the entire database plus all 
> indexes in memory. I will keep my fingers crossed this problem just goes 
> away, but if it doesn't, what else can I do when it occurs to help track 
> it down?

You didn't tell what hypervisor you are using, bu tdid you know that Xen PVMs 
support "memory hotplugging"?
You can add RAM while the OS is running (also works with CPUs), but it has to 
be prepared in config...

Regards,
Ulrich

Antw: [EXT] Re: slow memberOf queries in 2.5 with dynlist overlay

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 16.02.2022 um 06:13 in
Nachricht
<5f015d2d-8965-6c70-0c6d-7a96e9ec2...@acm.org>:
> On 2/15/2022 1:57 AM, Ondřej Kuzník wrote:
> 
>> - if, to answer that query, you need to crawl a large part of the DB,
>>the OS will have to page that part into memory
> 
> Do you know if there's any way to tell which pages of a memory mapped 
> file are actually in memory at any given time? The process map just 
> shows 5G (the max size I currently have configured for the database):
> 
>   7fece8cfb000 5242880K rw-s- data.mdb

"man pmap", maybe?

# pmap $$
21561:   -bash
Address   Kbytes RSS PSS   DirtySwap Mode  Mapping
558d2476d000 964 904 904   0   0 r-xp- /usr/bin/bash
558d24a5e000   8   8   8   8   0 r--p- /usr/bin/bash
558d24a6  16  16  16  16   0 rw-p- /usr/bin/bash
558d24a64000  56  44  44  44   0 rw-p-   [ anon ]
558d25ff70004464438443844384   0 rw-p-   [ anon ]
7f1ca39a80002528 192  35   0   0 r--p-
/usr/lib/locale/en_US.utf8/LC_COLLATE
7f1ca3c2  28  28   0   0   0 r-xp-
/lib64/libnss_compat-2.31.so
7f1ca3c270002048   0   0   0   0 ---p-
/lib64/libnss_compat-2.31.so
7f1ca3e27000   4   4   4   4   0 r--p-
/lib64/libnss_compat-2.31.so
7f1ca3e28000   4   4   4   4   0 rw-p-
/lib64/libnss_compat-2.31.so
7f1ca3e29000 152 152  38   0   0 r-xp-
/lib64/libtinfo.so.6.1
7f1ca3e4f0002044   0   0   0   0 ---p-
/lib64/libtinfo.so.6.1
[...]

> 
> Thanks…

Antw: [EXT] Re: slow memberOf queries in 2.5 with dynlist overlay

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 15.02.2022 um 03:01 in 
>>> Nachricht
:

...
>> How much RAM do you have on the system?
> 
> 2GB. I don't think I'm running low on memory, there's usually a bit
> free:
...

Independent of LDAP my guess is that 2GB is somewhat tight these days, and my 
guess is that it's virtual machine.
Some rules say you should have 0.5GB per core reserved for the OS, so if your 
DB size is 2GB, it looks a bit tight to me.

Don't get me wrong: We _are_ running a tiny BDB-based OpenLDAP on a two-CPU VM 
with 1GB RAM (actually it also runs a tiny apache web server, too), but for 
real servers, it's probably too tight.
# free -m
 total   used   free sharedbuffers cached
Mem:   953882 70 48151448
-/+ buffers/cache:282671
Swap: 2047 62   1985

Regards,
Ulrich

Antw: [EXT] Re: How to restrict access to pwdHistory attributes

[Ulrich Windl]

>>> Chandeshwar Mishra  schrieb am 14.02.2022 um
23:26 in Nachricht
:
> Hi Quanah,
> 
> Thanks for your response.  Our setup is a very old one and we are planning
> to migrate it to the latest stable version but Since this openldap is
> deployed in Production
> it is not possible for us to upgrade it suddenly.
> 
> As you mentioned that ppolicy schema is missing in configuration, so is it
> possible that without having ppolicy schema, Openldap will remember the
> pwdHistory of the user ?

My guess is that unconfiguring ppolicy does not make the entries created by 
ppolicy go away.
You probably have to remove them if you want them to go away, or re-confiugure 
ppolicy if you want to use them.

Regards,
Ulrich

> 
> In my case pwdHistory is visible to users, for which I want to apply ACL so
> that a user can only see his/her pwdHistory , not other users pwdHistory.
> 
> Below are my configuration related to ppolicy configuration in config file:-
> 
> include /etc/openldap/schema/ppolicy.schema
> --- more include directive related to schema
> 
> 
> moduleload ppolicy.la
> moduleload memberof.la
> overlay memberof
> overlay syncprov
> overlay auditlog
> #overlay accesslog
> overlay ppolicy
> ppolicy_default "cn=passwordDefault,dc=example,dc=com"
> 
> Thanks & Regards,
> Chandeshwar Kumar
> 
> 
> 
> 
> 
> On Mon, Feb 14, 2022 at 11:24 PM Quanah Gibson-Mount 
> wrote:
> 
>>
>>
>> --On Saturday, February 12, 2022 5:22 AM +
>> kumarchandeshwa...@gmail.com 
>> wrote:
>>
>> > Hi,
>> >  I am trying to restrict access to pwdHistory attributes provided by
>> > ppolicy overlay. I have applied the below ACL
>> >
>> > access to attrs=pwdHistory
>> >  by * none
>> >  but while doing slaptest,  its throwing below error:-
>> > /etc/openldap/slapd.conf: line 212: unknown attr "pwdHistory" in to
>> clause
>> >  ::= access to  [ by  [  ] [ 
>> > ] ]+  ::= * | dn[.=] [filter=]
>> > [attrs=]  ::= 
>> > [val[/][.]=] |   ::=
>> >  [ ,  ]
>> >  ::=  | @ | ! | entry |
>> children
>> >  ::= [ * | anonymous | users | self | dn[.]= ]
>> > [ realanonymous | realusers | realself | realdn[.]=
>> ]
>> > [dnattr=]
>> > [realdnattr=]
>> > [group[/[/]][.

Antw: [EXT] Re: log analysis tools

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 06.02.2022 um 03:19 in
Nachricht
:
> On Sat, Feb 05, 2022 at 09:57:15AM ‑0300, Andreas Hasenack wrote:
>> openldap also has a monitor backend IIRC, have you looked into that?
> 
> Yes, historically we've used that with icinga and munin, although we're
> looking to replace munin. That doesn't provide the per query timing
> analysis I'm looking for to address a specific performance issue though.

Anyway: Any plans for such (enhanced LDAP monitoring)? Or something like an
"explain" (that SQL databases do to explain how a query will be processes and
what the estimated costs are)?

Regards,
Ulrich

> 
> Thanks...

Antw: [EXT] [LMDB] mdb_env_set_mapsize and read transactions

[Ulrich Windl]

>>> "Ken Wenzel"  schrieb am 31.01.2022 um 08:16 in Nachricht
<002001d81672$866fdb30$934f9190$@gmx.net>:
> Hello,
> 
> 
> 
> I like to implement an autogrow functionality for LMDB.
> 
> The documentation for mdb_env_set_mapsize says that no transactions should
> be active when using this function.
> 
> When looking at the code I can see that the function only checks if there is
> an active WRITE transaction and in this case it returns an error.


Probably a classic example of underspecification: The developers reserve the 
right to change details later.
Obviously when mdb_ebv_set_mapsize does not relocate any blocks all 
tranbsactions should be able to continue, but as it seems, blocks may be 
reallocated during or after mdb_ebv_set_mapsize.

Regards,
Ulrich

> 
> 
> 
> Is it possible to reuse existing READ transactions or even associated
> cursors after mdb_env_set_mapsize has been called?
> 
> 
> 
> Thank you and best regards,
> 
> Ken

Antw: [EXT] Question regarding password dictionary rule in OpenLDAP

[Ulrich Windl]

>>> "Ulrich Windl"  schrieb am 28.01.2022 um
08:49 in Nachricht <61f3a01f02a100047...@gwsmtp.uni-regensburg.de>:
>>>> Alan Andrea  schrieb am 27.01.2022 um 17:04 in 
>>>> Nachricht
> <1969009486.3151222.1643299488...@mail.yahoo.com>:
>> I have a question regarding password rules that are enforced when a user 
>> changes their password in OpenLDAP.  We have a need to implement a 
> dictionary 
>> rule whereby words and phrases in a dictionary are not allowed in a users 
>> password.  I am not able to see currently where such functionality exists in 
> 
>> OpenLDAP and am wondering if there are any extensions to OPenLDAP that were 
>> developed to support this or if it would be required to write code to 
> support 
>> this feature?
> 
> AFAIK it would have to be done via password policy using a custom module 
> (unless something read for use exists already).

I had meant to write "... ready for use ...".

> See pwdCheckQuality, pwdCheckModule
> 
> Regards,
> Ulrich
> 
>> 
>> Thanks,Alan

Antw: [EXT] Question regarding password dictionary rule in OpenLDAP

[Ulrich Windl]

>>> Alan Andrea  schrieb am 27.01.2022 um 17:04 in 
>>> Nachricht
<1969009486.3151222.1643299488...@mail.yahoo.com>:
> I have a question regarding password rules that are enforced when a user 
> changes their password in OpenLDAP.  We have a need to implement a dictionary 
> rule whereby words and phrases in a dictionary are not allowed in a users 
> password.  I am not able to see currently where such functionality exists in 
> OpenLDAP and am wondering if there are any extensions to OPenLDAP that were 
> developed to support this or if it would be required to write code to support 
> this feature?

AFAIK it would have to be done via password policy using a custom module 
(unless something read for use exists already).
See pwdCheckQuality, pwdCheckModule

Regards,
Ulrich

> 
> Thanks,Alan

Minor typo in slapo-ppolicy

[Ulrich Windl]

Hi!

I just discovered a minor typo in my version of the slapo-ppolicy manual page 
(possibly it's fixed alrerady):
The manual page lists "pwdGraceAuthnLimit", but the attribute returned by 
slapcat is "pwdGraceAuthNLimit" (different case for 'N')
The name from the schema also is "pwdGraceAuthNLimit".

Regards,
Ulrich

Antw: [EXT] Re: Delta‑sync replication: is it possible to force resync delta?

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 20.01.2022 um 18:02 in
Nachricht <65ABF4684C2D1F77600EF736@[192.168.1.27]>:

> 
> ‑‑On Wednesday, January 19, 2022 4:26 PM +0200 skeletor 
>  wrote:
> 
>> Hi.
>> I use delta‑sync replication on version 2.4. Sometimes, some records
>> don't send to slave. Insofar as this is delta‑sync after a new update
>> slave receive only last update. Therefore slave and master are not
>> consistent. Is it possible run force resync from accesslog to consistent
>> check if all records are present on slave?
>> May be this is a bug on version 2.4 and it already has been fixed in
>> newer version?
>>
>> master 2.4.57
>> slave 2.4.55
> 
> I'm not quite sure what you mean by sometimes some records don't send to 
> the slave.  That would most generally indicate a configuration issue.  You 
> would want to see if the record exists in the accesslog DB of the provider 
> corresponding to the time it was added via an ldap operation (obviously, 
> any entries added offline via mechanisms like slapadd would never be 
> replicated).  I would also confirm that you do not see REFRESHes occurring 
> on the consumer vs the provider.  I would also confirm that you haven't run

> the accesslog database out of space preventing it from recording operations

> (the MDB maxsize for the accesslog db).
> 
> The only reliable way to get them in sync would be to slapcat the provider 
> and import it on the consumer.  However, given the description of the 
> problem from your end, I'm not convinced they wouldn't just de‑sync again.

Independent of this problem I wonder whether it is possible (proper access
rights assumed) to compare the contents of all mirroring servers via LDAP
efficiently.
It seems the seemingly random order of entries and attributes is the major
obstacle when searching just "for everything".
Also an operation like "resync fully from ServerID X" would seem to be a nice
idea.

Regards,
Ulrich

Antw: [EXT] Delta-sync replication: is it possible to force resync delta?

[Ulrich Windl]

>>> skeletor  schrieb am 19.01.2022 um 15:26 in Nachricht
<17e37982-716f-795c-e810-70c483b6d...@lissyara.su>:
> Hi.
> I use delta-sync replication on version 2.4. Sometimes, some records 
> don't send to slave. Insofar as this is delta-sync after a new update 
> slave receive only last update. Therefore slave and master are not 
> consistent. Is it possible run force resync from accesslog to consistent 
> check if all records are present on slave?
> May be this is a bug on version 2.4 and it already has been fixed in 
> newer version?
> 
> master 2.4.57
> slave 2.4.55

The answer you are going to hear will most likeley be this: 2.4 is obsolete and 
no longer supported.
Maybe if you got the software from your OS (e.g. SLES up to 12) and you have 
some maintenance contract, maybe they can help you.

Regards,
Ulrich

Antw: [EXT] Re: mmr of cn=config with OpenLDAP 2.6

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 10.01.2022 um 17:13 in
Nachricht :

> 
> ‑‑On Monday, January 10, 2022 5:02 PM +0100 Stefan Kania 
>  wrote:
> 
>> The problem is solved,
>> in my configuration I wrote:
>> 
>> dn: olcDatabase={2}mdb,cn=config
>> objectClass: olcmdbConfig
>> 
>> but with 2.6 ldapmodify is looking for:
>> objectClass: olcMdbConfig
>>
>> so it must be a capital "M". With a small "m" you will get "err=53"
>> "server unwilling to perform"
>>
>> @Quanah: In your blog about mmr it's also with a small "m", maybe you
>> can change it.
> 
> The fact that OpenLDAP is treating them as different values is a bug and 
> actively being worked on.  And why the issue you filed has not been closed 
> out. ;)

But maybe still the examples should contain the correct CamelCase as the words
are harder to read otherwise (olcmdbconfig).

> 
> ‑‑Quanah
> 
> 
> ‑‑
> 
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

Antw: [EXT] Re: Guide to setup syncrepl with proxy‑based push config

[Ulrich Windl]

>>> David White  schrieb am 04.01.2022 um 21:56 in
Nachricht
:
...

> root@ldap-provider:~# slapcat -b cn=config
> slapcat: could not open database.
> 
> root@ldap-provider:~# slapcat -n0
> slapcat: could not open database.

Did you try the -v or -d option to get more info?

...

Regards,
Ulrich

Antw: [EXT] Re: openldap ppolicy pwdAccountLockedTime

[Ulrich Windl]

>>> kevin martin  schrieb am 01.01.2022 um 00:00 in
Nachricht
:
> Pwdaccountlockedtime isn't an attribute that can be set in the database
> since ppolicy is now compiled into openldap as opposed to it being a schema
> that's pulled in and that attribute is not defined in the source code.  I
> would say that, based on the man page, it's a bug.

In 2.4 I can query it from cn=schema,cn=config:
( 1.3.6.1.4.1.42.2.27.8.1.17 NAME 'pwdAccountLockedTime' DESC 'The time an
user account was locked' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE
USAGE directoryOperation )

> 
> On Fri, Dec 31, 2021, 11:23 AM Michael Ströder 
wrote:
> 
>> On 12/27/21 12:04, Ulrich Windl wrote:
>> >>>> kevin martin  schrieb am 22.12.2021 um 22:42 in
>> Nachricht
>> > :
>> >> it appears from looking at ppolicy.c that pwdAccountLockedTime is not
>> >> supported in openlda.  is there another way to lock a users account in
>> >> openldap outside of simply changing the users password?
>> >
>> > I found out the hard way: When all grace logins were consumed after
>> > the user should have changed the password, the user can no longer log
>> > in (and he/she cannot change the password either).
>> But that's not what the original poster asked for.
>>
>> See slapo-policy(5) [1]:
>>
>> "If pwdAccountLockedTime is set to 0101Z, the user's account has
>> been permanently locked and may only be unlocked  by an administrator."
>>
>> IIRC this works. If not, then it's a bug.
>>
>> In Æ-DIR I let admins maintain a status attribute 'aeStatus' which is
>> also evaluated by ACLs on userPassword to deactivate authentication
>> (auth privilege granted to anonymous only for active entries).
>>
>> Ciao, Michael.
>>
>> [1] https://www.openldap.org/software/man.cgi?query=slapo-ppolicy 
>>

Antw: [EXT] openldap ppolicy pwdAccountLockedTime

[Ulrich Windl]

>>> kevin martin  schrieb am 22.12.2021 um 22:42 in Nachricht
:
> it appears from looking at ppolicy.c that pwdAccountLockedTime is not
> supported in openlda.  is there another way to lock a users account in
> openldap outside of simply changing the users password?

I found out the hard way: When all grace logins were consumed after the user 
should have changed the password, the user can no longer log in (and he/she 
cannot change the password either).

> 
> ---
> 
> 
> Regards,
> 
> Kevin Martin

Antw: [EXT] Re: symas openldap-packages and kerberos

[Ulrich Windl]

>>> Dieter Klünter  schrieb am 18.12.2021 um 07:28 in
Nachricht <20211218072816.769b4...@pink.fritz.box>:
> Am Fri, 17 Dec 2021 16:34:41 +0100
> schrieb Stefan Kania :
> 
>> Hello to all,
>> 
>> I'm trying to get GSSAPI authentication running with the
>> symas-packages. I generated a ldap.keytab file and it's readable for
>> the ldap-user running the slapd. With the Debian-packages I ad:
>> -
>> export KRB5_KTNAME="/path/to/ldap.keytab"
>> -
>> 
>> I don't want to use the system keytab /etc/krb5.keytab. How do I tell
>> slapd from the symas-packages to use my service-keytab?
>> 
>> I try to add to my /etc/default/symas-openldap:
>> -
>> KRB5_KTNAME="/path/to/ldap.keytab
>> -
>> but it's not working.
> 
> /etc/sasl2/slapd.conf
> mech_list: gssapi digest-md5 cram-md5 external
> keytab: /etc/openldap/ldap.keytab
> 
> /etc/ldap.conf
> KRB5_KTNAME=/etc/openldap/krb5.keytab
> SASL_MECH GSSAPI
> SASL_REALM My.SASL.REALM

Dieter,

I wonder: Did you "just know", or is that documented somewhere? If the latter,
maybe also add where you found those pearls of wisdom.

Regards,
Ulrich

> 
> -Dieter
> 
> -- 
> Dieter Klünter | Systemberatungslapd
> GPG Key ID: E9ED159B
> 53°37'09,95"N
> 10°08'02,42"E

Re: Antw: [EXT] OpenLDAP Upgrade

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 10.12.2021 um 18:00 in
Nachricht <2A5F43DA950658AE64FEE654@[192.168.1.3]>:

> 
> --On Friday, December 10, 2021 8:14 AM +0100 Ulrich Windl 
>  wrote:
> 
>>>> OpenLDAP 2.6 is the current release series.  OpenLDAP 2.4 is no longer
>>>> in support.  As I noted previously, Symas provides pre‑built binaries
>>>> via a repository as described at <https://repo.symas.com/soldap/>.  Paid
>>>> support is optionally available as well.
>>>
>>> Also, I'd note again that the vendor supplied builds are woefully out of
>>> date and are generally unsuitable for a production environment,
>>> especially  one running business critical applications.
>>
>> Well, as long as those vendors offer support for their packages it's
>> discussable whether those packages are suitable for production
>> environments. At the moment I'm taking part in some online training, and
>> I found out that the OS of the training environment had its last update
>> in 2019, so probably the effective date of the software is even older.
>> The company offering the training has _lots_ of money, however...
>>
>> Not all production environment needs bleeding edge software.
> 
> I'm not aware of any vendor that offers support for their OpenLDAP 
> packages.  RedHat in particular is most known for causing bugs (including 

You are right insofar as Redhat and SUSE both moved from openLDAP to 389ds in
their current releases, but before they actually back-ported fixes to their
OpenLDAP software packages.

> serious CVEs) in OpenLDAP with broken patches because they don't understand

> the code.  And the particular version of OpenLDAP 2.4 referenced here is 
> years out of date, with numerous critical bug fixes having occurred since 
> it was released.
> 
> Additionally, the packages provided for *free* by Symas are the same 
> packages used in production by our paying support customers, and critical 
> issues found therein are promptly fixed.  So *free* users get actual 
> support and benefit from using our packages that are not obtainable via 
> distribution provided packages.
> 
> Regards,
> Quanah
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>

Re: Antw: [EXT] OpenLDAP Upgrade

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 09.12.2021 um 17:54 in
Nachricht <9E71A1C6CC6C9A43887B2B56@[192.168.1.3]>:

> 
> ‑‑On Tuesday, December 7, 2021 8:39 AM ‑0800 Quanah Gibson‑Mount 
>  wrote:
> 
>>
>>
>> ‑‑On Tuesday, December 7, 2021 9:57 AM + santoshk.se...@tcs.com wrote:
>>
>>> Thanks Emmanuel,
>>> Is it a stable version we can reply upon? Because the request is for a
>>> production environment which are running critical business applications
>>>
>>> As part the OS upgrade (6.4 to 7.9),  the default OpenLDAP comes in
>>> RHEL7.9 is openldap‑servers‑2.4.44‑24.el7_9.
>>>
>>> This is a existing setup in production. We just want to upgrade it (rpm
>>> ‑Uvh) :) on the exisitng RPMs.
>>
>> OpenLDAP 2.6 is the current release series.  OpenLDAP 2.4 is no longer in
>> support.  As I noted previously, Symas provides pre‑built binaries via a
>> repository as described at .  Paid
>> support is optionally available as well.
> 
> Also, I'd note again that the vendor supplied builds are woefully out of 
> date and are generally unsuitable for a production environment, especially 
> one running business critical applications.

Well, as long as those vendors offer support for their packages it's
discussable whether those packages are suitable for production environments.
At the moment I'm taking part in some online training, and I found out that
the OS of the training environment had its last update in 2019, so probably
the effective date of the software is even older. The company offering the
training has _lots_ of money, however...

Not all production environment needs bleeding edge software.

Regards,
Ulrich

Re: Antw: [EXT] OpenLDAP Upgrade

[Ulrich Windl]

>>>  schrieb am 07.12.2021 um 10:57 in Nachricht
<20211207095727.5262.37...@hypatia.openldap.org>:
> Thanks Emmanuel,
> Is it a stable version we can reply upon? Because the request is for a 
> production environment which are running critical business applications
> 
> As part the OS upgrade (6.4 to 7.9),  the default OpenLDAP comes in RHEL7.9 
> is openldap-servers-2.4.44-24.el7_9.
> 
> This is a existing setup in production. We just want to upgrade it (rpm 
> -Uvh) :) on the exisitng RPMs.

Actually when you'd update you'd use "rpm -vF ..." I guess ;-)
But I'm unsure whether that will work "cross-vendor"; maybe check the file 
lists (rpm -qvlp ...) and compare with existng paths, also.
The best would probably be to have a snapshot-type backup (like for a VM 
shutting down, making a volume snapshot, then boot and trxy the update)

> 
> #rpm -qa | grep -i openldap
> openldap-2.4.23-31.el6.x86_64
> compat-openldap-2.3.43-2.el6.x86_64
> openldap-devel-2.4.23-31.el6.x86_64
> openldap-servers-2.4.23-31.el6.x86_64
> openldap-clients-2.4.23-31.el6.x86_64
> 
> 
> Thanks
> Santosh

Antw: [EXT] OpenLDAP Upgrade

[Ulrich Windl]

>>>  schrieb am 02.12.2021 um 11:28 in Nachricht
<20211202102836.5262.15...@hypatia.openldap.org>:
> HI,
> 
> We have OpenLDAP 2.4.xx running in RHEL6.4. We are planning to upgrade the 
> RHEL version to 7.9 and then upgrade the OpenLDAP to 2.6.
> 
> The OpenLDAP installed are all RPMs
> 
> #rpm -qa | grep -i openldap
> openldap-2.4.23-31.el6.x86_64
> compat-openldap-2.3.43-2.el6.x86_64
> openldap-devel-2.4.23-31.el6.x86_64
> openldap-servers-2.4.23-31.el6.x86_64
> openldap-clients-2.4.23-31.el6.x86_64
> 
> But the package for OpenLDAP available is binary packages. I need help how 
> to upgrade considering the existing LDAP database, schema and configuration 
> are required to be there after the upgrade.

I wonder why you don't consider RedHat resources first. I guess they have some 
docs for that.

> 
> 
> We have 2 Master server, 2 Consumer server and 2 loadbalancer running 
> keepalived.
> 
> Appreciate if anyone can help to upgrade the OS as well as the OpenLDAP 
> package.
> 
> Thanks
> Santosh

Q: Detect "user on grace logins" (ppolicy being used)?

[Ulrich Windl]

Hi!

I have a question: When using ppolicy, is tthere a simple way for a user to 
detect that he/she is "on grace logins", i.e. the poassword has to be changed 
soon?
We had a situation where some monitoring tools uses periodic logins to sume 
user account. When that user should have changed the password, the periodic 
logins consumed all the grace logins, and the user was effectively locked out.
While there are many ways to resolve this, I wonder whether it would be rather 
easy to avoid any further login attempts when the user is expected to change 
the password.

Regards,
Ulrich

Antw: [EXT] ppolicy-question

[Ulrich Windl]

>>> "A. Schulze"  schrieb am 26.11.2021 um 23:34 in
Nachricht :
> Hello,
> 
> using slapo-ppolicy I could configure slapd to hash a password if it's sent 
> unhashed.
> 
> moduleload ppolicy.la
> moduleload argon2.la
> password-hash {ARGON2}
> 
> database mdb
> suffix dc=test
> ...
> overlay ppolicy
> ppolicy_default "cn=default,ou=ppolicies,dc=test"
> ppolicy_hash_cleartext
> 
> 
> That work and I could hash them using ARGON2.
> 
> But clients could still hash a password them self and write '{MD5}...' as 
> userPassword for example.
> Is it possible to reject any userPasswords prefixed with hash schema?

But isn't the real question whether clients using MD5 can handle ARGON2?

> 
> Andreas

Aw: [EXT] Multi-Master not syncing

[Ulrich Windl]

Hi!


Maybe explain the steps you did to convert B from slave to master first.


Regards,
Ulrich


>>> Enrico Weigelt, metux IT consult 30.11.2021, 17:26 >>>
Hello friends,


I'm in huge trouble: my MMR setup (Zimbra) isn't syncing completely.

* host A is the old master, host B a new one.
* host B used to be a slave of A, but later was promoted to master
(each has a syncrepl pointer to the other and mirrormode is TRUE)
* sync from A to B seems to be fine, but the route back doesn't work
* new objects (eg. new users) are synced up from B to A, but later
changes don't get throught (eg. additional entries like mail aliases)

On host B i get lots of repeated log messages like this:

Nov 30 09:56:04 hz1-rz-mail-ldap-01 slapd[3999428]: conn=6002 op=1
syncprov_search_response: Entry uid=u37701,ou=people,dc=hs-harz,dc=de
CSN 20211129215211.258933Z#00#001#00 older or equal to ctx
20211130085608.894386Z#00#001#00

On Host A I'm getting lots of log messages like this:

Nov 30 10:12:38 inkataube slapd[17590]: dn_callback : new entry is older
than ours uid=g50425,ou=people,dc=hs-harz,dc=de ours
20211130032044.897539Z#00#001#00, new
20211130032015.857165Z#00#002#00

It looks like both nodes can't agree on what's the most recent entries.

Is there any way to force them taking either side's version ?


thanks

--mtx

---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Antw: [EXT] Re: contextCSN not updated

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 25.10.2021 um 17:15 in
Nachricht :

> 
> ‑‑On Monday, October 25, 2021 1:29 PM + bourgu...@gmail.com wrote:
> 
>> Dears,
>>
>> I found the cause if I can tell it like this, in fact, it's only for
>> cn=config for which there are replication settings set for the 4MMR but
>> not for the replica, then the contextCSN of replica isn't modified when I
>> do any kind of modification to its cn=config.
>>
>> I still have a question about it, is there a way to know if cn=config is
>> updated (in any area) for a replica which has not syncrepl accord ? like
>> contextCSN attribute ?
>>
>> I knew that entryCSN is modified for the object modified but it's object
>> by object and I'd like to have it globaly.
> 
> A contextCSN is only maintained on a database that is replicated.  If your 
> consumers don't also replicate cn=config, then there will not be any 
> contextCSN on the cn=config db.  One question would be, why do you have 
> consumers at all if you're running in an MMR environment?  Alternatively, 
> if there is some need that mandates consumers, there are examples in the 
> test suite on how to set things up so that a group of consumers share a 
> replicated database (See test059 or test086).

Hi!

The point is whether it was some historical design decision to make
slapo-syncprov provide the contextCSN.
It would be a rather handy modification timestamp for a database independently
from syncing.
My guess it that it might be rather easy to add it to the base slapd.

Also: Does contextCSN correspond to RFC 4533's syncCookie?

Regards,
Ulrich

> 
> Regards,
> Quanah
> 
> ‑‑
> 
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

Antw: [EXT] Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 21.10.2021 um 19:29 in
Nachricht <125627C2D6AF4AE00EF3FCDF@[192.168.1.11]>:

> 
> --On Thursday, October 21, 2021 7:54 PM +0300 Nick Milas 
>  wrote:
> 
>> On 21/10/2021 6:39 μ.μ., Nick Milas wrote:
>>
>>> From the journal, some excerpts (it is very long):
>>
>> My fault: I copied parts from the journal before the restart :(
>>
>> Here is the actual log after restart:
> 
> The client side still says it can't validate the cert.  As long as the 
> client can't validate the cert, you won't be able to establish TLS.
> 
>>From your ldapwhoami output:
> 
> TLS certificate verification: depth: 0, err: 20, subject: 
> /C=GR/ST=Attik\xC3\xAD/L=Athens/O=National Observatory of 
> Athens/CN=ldap1.noa.gr, issuer: /C=NL/O=GEANT Vereniging/CN=GEANT OV RSA CA

> 4
> TLS certificate verification: Error, unable to get local issuer certificate

Maybe use openssl x509 to display the certificate chain, looking for problems,
and use the "verify" of openssl to check the certificate (chain).
And show us the results ;-)

> 
> --Quanah
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

Antw: [EXT] Re: Symas OpenLDAP 2.5 RPMs run slapd as root?

[Ulrich Windl]

Hi!

Wondering about "LimitNOFILE=96": Wouldn't that limit the open sockets
(connections) as well?

Regards,
Ulrich

>>> Michael Ströder  schrieb am 19.10.2021 um 18:17 in
Nachricht :
> On 10/19/21 17:10, Quanah Gibson-Mount wrote:
>> --On Tuesday, October 19, 2021 1:00 AM -0700 "Paul B. Henson" 
>>  wrote:
>> 
>>> I'm testing openldap 2.5 in preparation for migration my production
>>> services, and I noticed that the 2.5 RPMs no longer create an ldap user
>>> and instead run slapd as root by default?
>> 
>> If you want it to run as a non-root user, it's on you to configure it as 
>> such, including said user.  The majority of Symas customers run as root.
> 
> IMHO there's no good reason to let systemd start slapd as root.
> 
> Binding to so-called "privileged ports" can be achieved by setting these 
> options in the systemd unit:
> 
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> AmbientCapabilities=CAP_NET_BIND_SERVICE
> 
> Also it's good practice to use systemd's sandboxing options based on 
> Linux namespaces. Read about various options called Protect*= and 
> Private*= in systemd.exec(5).
> 
> Nevertheless I also recommend to add a custom service account and set 
> ownership/permissions with a decent config management instead of adding 
> this to a RPM .spec or Debian package.
> 
> Find below ae-slapd.service generated by Æ-DIR's ansible role.
> 
> Ciao, Michael.
> 
> # /etc/systemd/system/ae-slapd.service
> #---
> # initiate:   systemctl enable ae-slapd.service
> # start:  systemctl start ae-slapd.service
> # get status: systemctl status ae-slapd.service
> #
> # Ansible managed: ansible-homelan/master
> #---
> 
> [Unit]
> Description=AE-DIR OpenLDAP server
> Requires=local-fs.target network.target
> After=local-fs.target network.target
> 
> [Service]
> Type=simple
> Environment=LD_PRELOAD=/usr/lib64/libtcmalloc.so.4
> Environment=LDAPNOINIT=1
> PIDFile=/run/ae-dir/slapd/slapd.pid
> ExecStart=/usr/lib64/slapd -d none -n ae-slapd -l LOCAL4 -s 7 -f 
> /opt/ae-dir/etc/openldap/slapd.conf -h 
> 'ldapi://%%2Frun%%2Fae-dir%%2Fslapd%%2Fldapi/x-mod=0777 ldap://*:389 
> ldaps://*:636' -o slp=off
> WorkingDirectory=/run/ae-dir/slapd
> User=ae-dir-slapd
> Group=ae-dir-slapd
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> AmbientCapabilities=CAP_NET_BIND_SERVICE
> LimitNOFILE=96
> RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
> # various hardening options from ansible var aedir_systemd_hardening
> UMask=0077
> PrivateUsers=no
> PrivateTmp=yes
> PrivateDevices=yes
> ProtectSystem=full
> ProtectProc=invisible
> ProtectHome=yes
> ProtectKernelModules=yes
> ProtectKernelTunables=yes
> ProtectKernelLogs=yes
> ProtectControlGroups=yes
> ProtectHostname=yes
> ProtectClock=yes
> NoNewPrivileges=yes
> MountFlags=private
> SystemCallArchitectures=native
> LockPersonality=yes
> KeyringMode=private
> RestrictRealtime=yes
> RestrictNamespaces=yes
> RestrictSUIDSGID=yes
> DevicePolicy=closed
> MemoryDenyWriteExecute=yes
> SystemCallFilter=~ @clock @cpu-emulation @debug @keyring @module @mount 
> @raw-io @reboot @swap @obsolete @chown @privileged @resources @pkey 
> @setuid @timer
> AppArmorProfile=ae-slapd
> 
> [Install]
> WantedBy=multi-user.target

Antw: [EXT] [LMDB] Performance on AWS/Windows

[Ulrich Windl]

>>> Jürgen Baier  schrieb am 07.10.2021 um 08:07 in
Nachricht
:
> Hi,
> 
> I'm using LMDB for mapping MD5 hash codes to some data. I noticed that a 
> virtualized environment (Xen/Windows on our own servers and AWS/Windows) 
> slows down LMDB significantly (e.g. a certain workload is executed in 30 
> minutes on a local machine vs. 15 hours on AWS).

I don't know whether Winows uses huge pages at all, but AFAIK huge pages are
unavaiable under Xen.
Maybe that makes a difference for large memory configurations (in addition to
the other things mentioned).
The other thing is whether your VM has a dedicated CPU or an "overcommitted"
shared CPU.

However 15 hours vs. 30 minutes sounds drastic.

> 
> My application also has an implementation in SQLite which is slower than 
> LMDB on a local machine. But its performance is similar on AWS. The 
> rough numbers are something like
> 
> Local:
> 
> - LMDB: 30 minutes
> - SQLite: 45 minutes
> 
> AWS:
> 
> - LMDB: 15 hours
> - SQLite: 50 minutes
> 
> I wanted to ask if there is something I can do to speed up LMDB on AWS? 
> Maybe I'm missing something obvious.
> 
> Thanks,
> 
> Jürgen
> 
> -- 
> Juergen Baier

Antw: [EXT] Re: 2.5.7 - help understanding syslog local4

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 23.09.2021 um 18:23 in
Nachricht :
> --On Thursday, September 23, 2021 6:45 PM +0200 Michael Ströder 
>  wrote:
> 
>>  Personally I have on my systems:
>>
>> In file /etc/systemd/journald.conf:
>>
>> [Journal]
>> Storage=none
>> ForwardToSyslog=yes
>>
>> In /etc/rsyslog.conf:
>>
>> $AddUnixListenSocket /dev/log
>>
>> And I start slapd with -d 0 and loglevel set.
> 
> As a side note, I've encountered deadlocks on RHEL7 on extremely busy 
> systems when journald is integrated with syslog like this.  It also has a 
> strong negative effect on performance.  Whether the deadlock is RHEL7 
> specific or not is unknown.
> 
> When OpenLDAP 2.6 releases, syslog (and journald) can be bypassed entirely 
> and a purely local log file can be used, resulting in a significant 
> performance increase.

Out of curiosity: When is that log file flushed (entry-based, time-based,
priority-based). It may make a difference when slapd crashes.

> 
> --Quanah
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

Antw: [EXT] Re: Communication exception during 500+ concurrent requests

[Ulrich Windl]

>>>  schrieb am 14.09.2021 um 11:56 in Nachricht
<20210914095659.5262.94...@hypatia.openldap.org>:
> Thank you for your prompt response and suggestion, Howard.
> I did try your suggestion and increased the olcListenerThreads (based on 
> number of CPUs) but that did not help. Got the same connection timeout errors 
> when I tried to go beyond 1650 concurrent requests.
> 
> Although, I did see something and wanted to run by you - In the 
> "libraries/libldap_r/tpool.c" code file I see that the max threads was 
> defined to "LDAP_MAXTHR 1024". So does that mean the limit on the number 
> of threads for slapd process is 1024 ? 
> 
> After coming across this setting we changed the number of threads in our 
> load test tool to 1024 for each node and ran that script 100 times in a loop 
> and we were able to successfully complete 204,800 bind requests across 2 
> nodes in 40 minutes. 
> 
> If we want to bump up the max thread number further to say 4096 can we do 
> that by just updating the "LDAP_MAXTHR" accordingly ? Will it affect 
> something else ? Thank you for your help as always !

Some years ago I had developed two versions of a test program on a 32-bit 
laptop; one was using processes, the other was using threads.
Amazingly I could run more processes than threads, because I ran out of virtual 
address space (each thread allocates a stack). At that time reducing the 
default thread stack size to the actual needs fixed the problem. Today with 64 
bits such a problem (running out of virtual address space) should be no issue. 
But still there might be oher limits you can hit.

Regards,
Ulrich

Antw: [EXT] Re: openSUSE/SLE users, migrate to back-mdb now!

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 26.08.2021 um 18:26 in
Nachricht :

> 
> --On Thursday, August 26, 2021 10:49 AM +0200 Michael Ströder 
>  wrote:
> 
>> On 8/26/21 9:41 AM, Ulrich Windl wrote:
>>> Honestly I'm quite afraid of the "space explosion" that seems to be an
>>> inherent feature of MDB. 8-(
>>
>> It's hard to tell about which problem you're talking without the usual
>> technical details:
>> - OS version
>> - OpenLDAP version
>> - which packages you're using
>> - detailed example data
>>
>> In my personal experience in customer projects migrating to back-mdb is
>> a no-brainer.
>>
>> Just do it now.
> 
> 
> back-mdb databases are literally smaller than the same back-bdb/hdb db, so 
> I've no clue what is being refernced here either.  It is true in some early

> releases of back-mdb there were some issues with fragmentation but that's 
> been dealt with.

Hi Quanah!

So are you saying with repeated modify operations MDB does no longer grow and
grow?
I got the impression that is does and you'll have to reorganize (export/imort)
the database periodically to keep the size in bounds.

Regards,
Ulrich


> 
> --Quanah
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>

Antw: [EXT] openSUSE/SLE users, migrate to back-mdb now!

[Ulrich Windl]

Hi!

Honestly I'm quite afraid of the "space explosion" that seems to be an
inherent feature of MDB. 8-(
(Maybe that's just because of my bad experience with earlier BtrFS filesystem
(that seems to use similar concepts IMHO))

Regards,
Ulrich

>>> Michael Ströder  schrieb am 25.08.2021 um 13:43 in
Nachricht <62996401-b45d-898d-3b6b-eab38b80a...@stroeder.com>:
> HI!
> 
> This is an important note to those who run OpenLDAP slapd based on
> openSUSE or SLE packages, especially Tumbleweed:
> 
> If you're still using OpenLDAP 2.4 or earlier with back-bdb or back-hdb
> then migrate to back-mdb now because OpenLDAP 2.5 packages won't support
> these backends anymore!
> 
> Disclaimer:
> 
> I'm writing as a package maintainer who only updates package "openldap2"
> in openSUSE Factory/Tumbleweed. I have no official role in openSUSE
> project nor SUSE.
> 
> Background:
> 
> As you might already know OpenLDAP 2.5 builds by default have no more
> support for backends back-hdb and back-bdb based on Berkeley-DB.
> Furthermore using Berkeley-DB in general is deprecated.
> 
> I've received a request to update the openSUSE package "openldap2" and
> its sub-packages to OpenLDAP release 2.5.7 also removing back-bdb and
> back-hdb [1]. I'd love to accept this update request really soon because
> I also want to have the new features in libldap. So the update will hit
> openSUSE Tumbleweed really soon.
> 
> While this change will *not* affect your deployments based on packages
> from SLE or openSUSE Leap 15.3 or earlier you should prepare your
> installation for possible future updates by migrating to back-mdb now.
> 
> And always use slapcat to backup your database(s) and practice restoring
> your databases to be prepared for any desaster.
> 
> Ciao, Michael.
> 
> [1] https://build.opensuse.org/request/show/914040 

Antw: [EXT] Re: migrate from 2.4 to 2.5, determine existing MDB format

[Ulrich Windl]

Hi!

It might get interesting if you sync cn=config, however.

Regards,
Ulrich

>>> kevin martin  schrieb am 19.08.2021 um 19:35 in Nachricht
:
> i understand that ldap is a protocol but it occurred to me that a database
> change (where tables and the like might be different and slapd version
> dependent) might need to be a sitewide thing, not a server by server thing
> (meaning the 2.4 servers, once the "database" is mirrored from the master
> server, might not understand the new format?).
> ---
> 
> 
> Regards,
> 
> Kevin Martin
> 
> 
> On Thu, Aug 19, 2021 at 12:31 PM Quanah Gibson-Mount 
> wrote:
> 
>>
>>
>> --On Thursday, August 19, 2021 1:23 PM -0500 kevin martin
>>  wrote:
>>
>> >
>> >
>> > if I have multiple slapd servers running 2.4 can I update my master
>> > server to 2.5 with the new format and will the 2.4 mirrors be able to
>> > handle the new format or is it an all or nothing upgrade of all servers
>> > at once?
>>
>> LDAP is a protocol, the internal change to the MDB database structure is
>> immaterial.
>>
>> --Quanah
>>
>> --
>>
>> Quanah Gibson-Mount
>> Product Architect
>> Symas Corporation
>> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
>> 
>>

Re: Antw: [EXT] Re: Index seems to return wrong amount of candidate causing really poor search performance

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 18.08.2021 um 17:34 in
Nachricht <1ACF53407B440BCD96A18A3F@[192.168.1.4]>:

> 
> ‑‑On Wednesday, August 18, 2021 9:15 AM +0200 Ulrich Windl 
>  wrote:
> 
>>> idlexp value increases the index slot range by a power of 2.  The
>>> largest
>>
>> Did you mean "to a power of 2", or do you really mean "by a power of 2"?
> 
> It increases by a power of 2, as documented in the man page.
> 
> idlexp _exp_
>   Specify a power of 2 for the maximum size of an index slot. 
> The
>   default is 16, yielding a maximum slot size of  2^16  or 
> 65536.
>   Once  set,  this  option applies to every mdb database 
> instance.
>   The specified value must be in the range of 16‑31.

Still I'm slighly confused:
If the default is 16 and you set it to (let's say) 18, by which power of two
will the value be increased?
2^18 - 2^16 is not a power of 2, so you could increase the value three times
by 2^16 (one to make 2^17, and another two to make 2^18).
But I still guess the value is simply set to 2^18, whatever the increase from
the default might be.
Can you confirm?

Regards,
Ulrich

> 
> 
> ‑‑Quanah
> 
> 
> ‑‑
> 
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>

Antw: [EXT] Re: Index seems to return wrong amount of candidate causing really poor search performance

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 16.08.2021 um 23:20 in
Nachricht <45379D5CBFA94DE3B1EA38E5@[192.168.1.4]>:

> 
> ‑‑On Monday, August 16, 2021 10:00 PM + Petteri Stenius 
>  wrote:
> 
>>
>> Thank you for your quick response.
>>
>>
>> If idlexp is the accepted solution then I'd like to understand how to
>> choose correct value for idlexp?
>>
>>
>> I have quickly tested with most values. With my quick tests I could not
>> find any significant impact on performance. Setting idlexp to maximum 31
>> did however cause slapd to crash with segmentation fault on my system.
> 
> The appropriate value for any environment is entirely dependent on that 
> environment's indexing and attribute value distribution for those indexed 
> attributes.  You generally want the minimum value for idlexp that allows 
> searches to function without performance problems.  Increasing the idlexp 
> size increases slapd memory usage.  Keep in mind that every increase in the

> idlexp value increases the index slot range by a power of 2.  The largest 

Did you mean "to a power of 2", or do you really mean "by a power of 2"?

> value I've ever needed for a massively large db with wide value 
> distributions was 22.

...

Regards,
Ulrich

Antw: [EXT] Profiling ACLs

[Ulrich Windl]

>>> Michael Ströder  schrieb am 11.08.2021 um 15:58 in
Nachricht <68f0b325-4ad4-7b86-d5be-a6a98aa07...@stroeder.com>:
> HI!
> 
> How to profile performance of different ACLs?
> 
> In theory one could run slapd with debug symbols under control of a
> profiler for C code. But personally I don't have a clue which ACL
> processing entry points to examine more closely.

What if you measure the performance on the client side?
I mean: If the client does not see a significant difference, the server's
performance may be more or less the same, too.
Or just measure how much I/O or CPU load the server is generating while you do
your client tests.
You could evaluate which ACLs are preferrable, but it does not tell you
whether or where you could improve the servers ACL processing...

Regards,
Ulrich

> 
> Another approach could be to derive metrics from acl-loglevel messages.

Maybe it would be preferable if monitoring were enhanced to include some
break-down of processing, like:
* parsing the request
* preparing the request (checking whether is is valid, probably including ACLs
processing time here)
* executing the request

The values could be per connection or as totals (or both)

Regards,
Ulrich

> 
> Any ideas?
> 
> Ciao, Michael.

Antw: [EXT] order of clauses in ACLs

[Ulrich Windl]

>>> Michael Ströder  schrieb am 11.08.2021 um 16:36 in
Nachricht :
> HI!
> 
> Frankly I forgot whether I asked this before:
> 
> Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".."
> in the  clauses.
> 
> Obviously depending on complexity of regex-pattern and length of DNs /
> avals the regex checking is more expensive than equality checking of
attrs=.
> 
> Can I improve ACL performance by order of  clauses or are they
> processed in fixed order anyway? If in fixed order, which one?

I don't know what regex library slapd uses, nor do I know whether slapd caches
compiled regex, but both could be important.
If you know what regex library it is, you could try different regex in a
stand-alone testing program to find out what costs most performance.
However my guess was that on modern machines regex performance shouldn't
matter unless the regex needs some unbounded look-ahead or backtracking.
I'd be surprised if any is needed in LDAP ACLs.

Maybe you give an example of your regex?

Regards,
Ulrich

> 
> Ciao, Michael.

Antw: [EXT] counters in cn=Waiters,cn=Monitor?

[Ulrich Windl]

>>> Michael Ströder  schrieb am 11.08.2021 um 19:48 in
Nachricht :
> HI!
> 
> I'm looking at a Prometheus graph of cn=Read,cn=Waiters,cn=Monitor
> (slapd 2.4.59).
> 
> The object class is monitorCounterObject, the attribute is called
> monitorCounter.
> 
> If it's a counter I'd expect the value to only increase.
> 
> But the graph shows decreasing values!?!
> 
> What's the exact meaning of this?

My guess is that it's a "gauge", not a "counter".

Seeing:
# Read, Waiters, Monitor
dn: cn=Read,cn=Waiters,cn=Monitor
monitorCounter: 15

here I guess it's the number of read threads waiting.

# Waiters, Monitor
dn: cn=Waiters,cn=Monitor
description: This subsystem contains information about read/write waiters.

Regards,
Ulrich

> 
> Ciao, Michael.

Antw: [EXT] Re: counters in cn=Waiters,cn=Monitor?

[Ulrich Windl]

>>> Howard Chu  schrieb am 11.08.2021 um 19:59 in Nachricht
<588cc1a2-4efd-e0e5-94a6-d550319fc...@symas.com>:
> Michael Ströder wrote:
>> HI!
>> 
>> I'm looking at a Prometheus graph of cn=Read,cn=Waiters,cn=Monitor
>> (slapd 2.4.59).
>> 
>> The object class is monitorCounterObject, the attribute is called
>> monitorCounter.
>> 
>> If it's a counter I'd expect the value to only increase.
>> 
>> But the graph shows decreasing values!?!
>> 
>> What's the exact meaning of this?
> 
> It's an instantaneous/current count, not cumulative.
> 
> The number of connections currently blocked waiting for data from the 
> client.
> 
> write waiters is the number of connections blocked waiting to send data to 
> the client.

Do do the recent versions have a "description" better than this old one?:
# Waiters, Monitor
dn: cn=Waiters,cn=Monitor
description: This subsystem contains information about read/write waiters.

Despite of that: Have you considered introducing a "monitorGauge" for those?
Also: is the value "right at the moment", or is it some sum or avarage for a
time interval (like one second)?

Regards,
Ulrich

> 
>> Ciao, Michael.
>> 
> 
> 
> -- 
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com 
>   Director, Highland Sun http://highlandsun.com/hyc/ 
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/ 

Antw: [EXT] Re: counters in cn=Waiters,cn=Monitor?

[Ulrich Windl]

>>> Michael Ströder  schrieb am 11.08.2021 um 20:50 in
Nachricht <56a569c5-658d-86f6-18b9-eda2194f9...@stroeder.com>:
> On 8/11/21 7:59 PM, Howard Chu wrote:
>> Michael Ströder wrote:
>>> I'm looking at a Prometheus graph of cn=Read,cn=Waiters,cn=Monitor
>>> (slapd 2.4.59).
>>>
>>> The object class is monitorCounterObject, the attribute is called
>>> monitorCounter.
>>>
>>> If it's a counter I'd expect the value to only increase.
>>>
>>> But the graph shows decreasing values!?!
>>>
>>> What's the exact meaning of this?
>> 
>> It's an instantaneous/current count, not cumulative.
>> 
>> The number of connections currently blocked waiting for data from the 
> client.
>> 
>> write waiters is the number of connections blocked waiting to send data to

> the client.
> 
> Hmm, so the schema used beneath cn=Threads,cn=Monitor would be more
> appropriate.

There, each value has a "description" at least (in my old version), but the
value is "very generic" (monitoredInfo) IMHO:
# Starting, Threads, Monitor
dn: cn=Starting,cn=Threads,cn=Monitor
monitoredInfo: 0
description: Number of threads being started

Regards,
Ulrich

> 
> Ciao, Michael.