Hi Quanah/all,

Well, once I used the suggestions below, everything loaded and went fine.

As part of my documentation and verification process:

systemctl stop slapd

rm -rf /etc/openldap/slapd.d/* /var/lib/ldap/*

and redo the whole process......

I gives me an invalid credentials issue now when I try to load the memberof.ldif file.

However, trying to re-load all the information via below and the correct cn=root works just fine.

I went through my history, I haven't changed anything yet I'm getting invalid credentials.

Now... here's some relevant information about this... and YES I KNOW IT SHOULD NOT MAKE A DIFFERENCE

It's a VM. I'm logged in via SSH and I'm also on the console.

I think this has something to do with the effective versus real UID, GID.

I ssh via an unprivilege'd user and su to root with: su - (I'm old pre-sudo)

I get invalid credentials....

I got thoroughly flustered.

Without changing anything except the slapd running: slapd -d -1 (in the SSH window)

I go to the root window on the VM console. I run the same command and it loads fine! Same password etc.

Just wow... everything is running fine. *shrug*

Just an fyi.

On Tuesday, September 10, 2019, 2:29:36 PM EDT, Quanah Gibson-Mount <quanah@symas.com> wrote:

--On Tuesday, September 10, 2019 5:19 PM +0000 Paul Pathiakis
<pathiaki2@yahoo.com> wrote:
> authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
"cn=root,dc=hq,dc=example,dc=com"
> rootdn "cn=root,dc=hq,dc=example,dc=com"
> rootpw {SSHA}7gMfpdvYlzgd4EmH3VbBCUsMHugjozU+

So you have two methods of accessing the rootdn for this database. Either
using SASL/EXTERNAL as root, or via -D/-W combination, with whatever
password you hashed to create the above SSHA hash. Only you would know
what that password is.

> loglevel -1

-1 is a debug level, not a log level. See the slapd.conf(5) man page for
valid log levels.

> I copied /usr/share/doc/openldap/DB_CONFIG.EXAMPLE /var/lib/ldap/DB_CONFIG

DB_CONFIG only applies to back-bdb and back-hdb databases. You are using
back-mdb, so it does nothing.

> ldapadd -f /etc/openldap/20160826-163635.ldif -v -D "cn=config" -H
> ldap://newldap.hq.example.com -W -c

cn=config doesn't have access to the binary database, so this is expected.
Use the correct rootdn (cn=root,dc=hq,dc=example,dc=com).

--Quanah

--

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