MacOS – Given the same remote LDAP server, why does Directory Utility work on one machine but not on the other

I have an LDAP server (OpenLDAP) running under Ubuntu 20.04 that I use for user authentication in my network, which consists of Linux servers and MacOS 11 clients. On my desktop, which runs MacOS 11.1, I can use Directory Utility to access the LDAP database without any problems.

I have a MacMini that I upgraded last week to MacOS 11.2. When I try to use Directory Utility on that machine, I get the error "Connection failed to the directory server (2100)" as soon as I select the LDAP server (as "/LDAPv3/servername") and before any prompt for username and password.

There is a known problem with logging in to remote LDAP servers that can be resolved by executing the following script:

#! /bin/bash

for f in /Library/Preferences/OpenDirectory/Configurations/LDAPv3/*
do
  LDAP_SERVER=`/usr/bin/basename $f ".plist"`
  echo $LDAP_SERVER

  SASL_MECHANISMS="`/usr/bin/ldapsearch -x -h $LDAP_SERVER -b '' -s base -LLL "(objectclass=*)" supportedSASLMechanisms | awk '{if($2 != "") printf "%s ",$2}'`"
  echo "  $SASL_MECHANISMS"

  /usr/bin/odutil set configuration /LDAPv3/$LDAP_SERVER  module ldap option "Denied SASL Methods" $SASL_MECHANISMS

done

I have executed this on both the desktop and the MacMini. So it seems that I have a different problem.

I looked at the log file of the LDAP server to see what happened when I selected /LDAPv3/servername and got the following:

Feb  7 01:42:17 s-tow-00 slapd[65708]: conn=1266 fd=16 ACCEPT from IP=192.168.1.32:54621 (IP=0.0.0.0:389)
Feb  7 01:42:17 s-tow-00 slapd[65708]: conn=1266 fd=16 closed (connection lost)

Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1267 fd=16 ACCEPT from IP=192.168.2.127:65230 (IP=0.0.0.0:389)
Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1267 fd=16 closed (connection lost)
Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1268 fd=16 ACCEPT from IP=192.168.2.127:65231 (IP=0.0.0.0:389)
Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1268 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1268 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1268 op=0 ENTRY dn=""
Feb  7 01:42:28 s-tow-00 slapd[65708]: conn=1268 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=

The MacMini (conn=1266, IP=192.168.1.32) returns immediately, whereas the desktop (1267, 1268, 192.168.2.127) proceeds to initiate a query.

I looked at the files in /Library/Preferences/OpenDirectory/Configurations/LDAPv3 on both machines to see if there was any difference there. Both contain entries for my LDAP servers (let's call them server1 and server2). On the desktop, their permissions were 0644, whereas on the MacMini they were 0600. I cannot change the permissions with chmod (thank you, SIP), so I started Directory Utility with sudo, but the problem still persisted, so I conclude that it has nothing to do with permissions.

I then experimented with dscl in interactive mode. On the desktop I got the following:

> ls /LDAPv3/server1
Automount
AutomountMap
CertificateAuthorities
Groups
Mounts
OrganizationalUnit
People
Users

whereas all the MacMini could manage was

> ls /LDAPv3/server1
ls: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)

I'm at a bit of a loss knowing how to proceed. I thought about exporting the configuration from the desktop using Directory Utility's "Write to Server" and then importing it on the MacMini, but I get "Operation is not supported by the directory node.", which I guess means that I have configured something incorrectly. I can "Save Template…", but the directory that I was told was intended for templates (~/Library/Application Support/Directory Access/LDAPv3/Templates) is stubbornly ignored on the MacMini.

Does anyone have any suggestions, please, as to how to proceed?

Steve