After install the openldap (slapd) from Debian package repository (using the version 2.4.57+dfsg-3~bpo10+1, database created by the dpkg configuration script provide by apt), the admin user (cn=admin,dc=example,dc=com) in could not be found either when performing ldapsearch or viewing the structure of the organisation in phpldapadmin / Apache directory studio.
result of ldapsearch: ------------ root@ldap:~# ldapsearch -x -b "dc=example,dc=com" # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# example.com dn: dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: example.com dc: exmaple
# search result search: 2 result: 0 Success ------------
However, using ldapwhoami (ldapwhoami -vvv -h ldap.example.com -D cn=admin,dc=example,dc=com -x -w password) can return a successful result.
result of ldapwhoami: ------------ ldap_initialize( ldap://localhost ) dn:cn=admin,dc=example,dc=com Result: Success (0) ------------
A similar issue can be found here: https://github.com/osixia/docker-openldap/issues/555 on Github. According to the user in Github, this issue is first occurred in openldap 2.4.57 (https://github.com/osixia/docker-openldap/releases/tag/v1.5.0 I'm not sure whether it is a feature or a bug of slapd. Thanks in advance!
On 4/29/22 19:44, sparkcyf@foxmail.com wrote:
After install the openldap (slapd) from Debian package repository (using the version 2.4.57+dfsg-3~bpo10+1, database created by the dpkg configuration script provide by apt), the admin user (cn=admin,dc=example,dc=com) in could not be found either > However, using ldapwhoami (ldapwhoami -vvv -h ldap.example.com -D cn=admin,dc=example,dc=com -x -w password) can return a successful result.
The rootdn of a database does not have to exist (and IMO should not exist and should not be used except for initializing the directory).
result of ldapwhoami:
ldap_initialize( ldap://localhost ) dn:cn=admin,dc=example,dc=com Result: Success (0)
Looks good to me.
Ciao, Michael.
Hello,
On Fri, Apr 29, 2022 at 05:44:38PM -0000, sparkcyf@foxmail.com wrote:
After install the openldap (slapd) from Debian package repository (using the version 2.4.57+dfsg-3~bpo10+1, database created by the dpkg configuration script provide by apt), the admin user (cn=admin,dc=example,dc=com) in could not be found either when performing ldapsearch or viewing the structure of the organisation in phpldapadmin / Apache directory studio.
Quoting from the changelog:
openldap (2.4.51+dfsg-1) unstable; urgency=medium [...] * Remove the redundant cn=admin,<suffix> entry from the default DIT for new installs. For new installs going forward, the root credentials will be stored in olcRootDN/olcRootPW only. (Closes: #821331)
This change was done to address the issue where the admin's password was stored in two places (olcRootPW and the entry's userPassword), which occasionally caused confusion if only one of the two was changed.
Hope this helps.
On 4/29/22 21:25, Ryan Tandy wrote:
On Fri, Apr 29, 2022 at 05:44:38PM -0000, sparkcyf@foxmail.com wrote:
After install the openldap (slapd) from Debian package repository (using the version 2.4.57+dfsg-3~bpo10+1, database created by the dpkg configuration script provide by apt), the admin user (cn=admin,dc=example,dc=com) in could not be found either when performing ldapsearch or viewing the structure of the organisation in phpldapadmin / Apache directory studio.
Quoting from the changelog:
openldap (2.4.51+dfsg-1) unstable; urgency=medium [...] * Remove the redundant cn=admin,<suffix> entry from the default DIT for new installs. For new installs going forward, the root credentials will be stored in olcRootDN/olcRootPW only. (Closes: #821331)
This change was done to address the issue where the admin's password was stored in two places (olcRootPW and the entry's userPassword), which occasionally caused confusion if only one of the two was changed.
Makes perfect sense to me.
I'd even avoid setting a rootpw value at all.
Ciao, Michael.
--On Friday, April 29, 2022 10:40 PM +0200 Michael Ströder michael@stroeder.com wrote:
This change was done to address the issue where the admin's password was stored in two places (olcRootPW and the entry's userPassword), which occasionally caused confusion if only one of the two was changed.
Makes perfect sense to me.
I'd even avoid setting a rootpw value at all.
How would one then add the initial database? What you suggest is all fine and good if someone has a known good LDIF to start from, a beginner isn't going to and will need to be able to get the error checking that slapadd does not provide.
--Quanah
On 4/29/22 23:21, Quanah Gibson-Mount wrote:
--On Friday, April 29, 2022 10:40 PM +0200 Michael Ströder michael@stroeder.com wrote:
This change was done to address the issue where the admin's password was stored in two places (olcRootPW and the entry's userPassword), which occasionally caused confusion if only one of the two was changed.
Makes perfect sense to me.
I'd even avoid setting a rootpw value at all.
How would one then add the initial database? What you suggest is all fine and good if someone has a known good LDIF to start from, a beginner isn't going to and will need to be able to get the error checking that slapadd does not provide.
Hmm, being the author of a generic LDAP client I can say that it's really hard to guide a newbie user to do the right thing when starting with an *empty* DB.
But I appreciate any hints how to do that, even if it requires to set rootpw. ;-)
The only viable solution is to provide decent tooling for setting up a DB with presets. If going this route you can also setup an admin group with decent ACLs right from the start. And the setup process can run as root connecting via LDAPI and using SASL/EXTERNAL for authc. Then running the setup as system user root is the initial trust anchor for boot-strapping the directory. Well, *you* already know all this and you probably guessed it: That's how Æ-DIR setup is doing it (and all automated setups I do for customers).
Ciao, Michael.
--O
How would one then add the initial database? What you suggest is all fine and good if someone has a known good LDIF to start from, a beginner isn't going to and will need to be able to get the error checking that slapadd does not provide.
Hmm, being the author of a generic LDAP client I can say that it's really hard to guide a newbie user to do the right thing when starting with an *empty* DB.
But I appreciate any hints how to do that, even if it requires to set rootpw. ;-)
The only viable solution is to provide decent tooling for setting up a DB with presets. If going this route you can also setup an admin group with decent ACLs right from the start. And the setup process can run as root connecting via LDAPI and using SASL/EXTERNAL for authc. Then running the setup as system user root is the initial trust anchor for boot-strapping the directory. Well, *you* already know all this and you probably guessed it: That's how Æ-DIR setup is doing it (and all automated setups I do for customers).
Yeah, I prefer the ldapi:// + EXTERNAL route as well, but that becomes somewhat more complicated (but of course not impossible) if you're using different rootdns for cn=config vs the other databases. Some sites require a high level of separation.
--Quanah
On 4/30/22 00:53, Quanah Gibson-Mount wrote:
The only viable solution is to provide decent tooling for setting up a DB with presets. If going this route you can also setup an admin group with decent ACLs right from the start. And the setup process can run as root connecting via LDAPI and using SASL/EXTERNAL for authc. Then running the setup as system user root is the initial trust anchor for boot-strapping the directory. Well, *you* already know all this and you probably guessed it: That's how Æ-DIR setup is doing it (and all automated setups I do for customers).
Yeah, I prefer the ldapi:// + EXTERNAL route as well, but that becomes somewhat more complicated (but of course not impossible) if you're using different rootdns for cn=config vs the other databases. Some sites require a high level of separation.
In my setups the rootdn of the "admin" DB is used in ACLs of the other DBs. That's what you probably meant.
If an auditor would question that I'd argue that system user "root" already has full access to the DB files and that my ACLs simply repeat that authorization.
Yes, in a customer project an auditor already asked who the rootdn in 'modifiersName' is. And we had to explain to him that some modifications were done initially during setup or are done by overlays with that identity. And in such a case it's very nice being able to clearly state that nobody can authc as this identity from remote or from an unprivileged process.
Ciao, Michael.
Got it, looks like such config is a feature of new version of slapd. The reason for posting this question is that I would have liked to change the password for cn=admin, but all the posts on the internet say that you need to change the password for both rootDN and configDN, which caused some confusion for me.
Anyway, thanks for the answer!
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy -
Spark F -
sparkcyf＠foxmail.com