Talk:OpenLDAP

Proposing adding section on groups/memberof.so --StrayArch (talk) 15:37, 28 June 2017 (UTC)

I suggest replacing the line # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/ with $ sudo -u ldap slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/

This avoids the need to fix the ownership of /etc/openldap/slapd.d/* again. --Langen (talk) 09:32, 6 September 2017 (UTC)

You could still improve the original wiki line with: slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/; chown -R ldap:ldap /etc/openldap/* that way you always ensure everything in /etc/openldap is owned by the ldap user and group Cirkit (talk) 00:37, 17 September 2017 (UTC)

During the rewrite, I have mentioned both methods. If this is satisfactory, please remove this discussion. Else, please suggest optimizations :) Logolive (talk) 12:32, 23 June 2021 (UTC)

slapd.conf(5) is deprecated

Configuration is now performed with a slapd-config(5) LDIF database.

Official OpenLDAP documentation mentions: The older style slapd.conf(5) file is still supported, but its use is deprecated and support for it will be withdrawn in a future OpenLDAP release

slapd might be considered "deprecated", but that doesn't mean it still cannot be used. The slapd.conf file is still useful and can assist with cn=config using slaptest as outlined in this wiki. IMO there is a lack of official documentation around the use of cn=config. Also, OpenLDAP's official documentation hardly even touches on the use of cn=config. Cirkit (talk) 19:07, 18 September 2018 (UTC)

I suggest we provide some info on cn=config. Eventually we need to switch to it. Also it seems cent os does a setup of cn=config with unix acl so some guide acually rely on that. 12:44, 4 March 2021 (UTC)

By now, there is at least some documentation on it. The official documentation has a chapter on basic configuration and this was very helpful, even if not always completely aware of all possibilities. So, as elaborated on below, I am in favor of switching.Logolive (talk) 13:03, 12 April 2021 (UTC)

Has been switched. Please review any changes :) Logolive (talk) 12:32, 23 June 2021 (UTC)

Actually, the entire Installation process needs an overhaul

There are several problems. As mentioned above, slapd.conf is depricated. Also, I think that it is not a good idea to encourage people to expose their database to all interfaces, as is the case here. Finally, there is no mention that slapd comes with a systemd service file, so we should mention this.

I am offering a new installation procedure for the server, open for discussion:

1. Install openldap via pacman

2. Create a minimal OLC (cn=config) configuration ldif file as shown below, where we point out the possibility to include further schemes and create indexes. The user needs to supplement their own domain/other suffix and generate a password via $ slappasswd

3. Import this file via $ slapadd -n 0 -F /etc/openldap/slapd.d/ -l file run as the ldap user

4. Mention the possibility to edit the systemd service file to only expose the database to the local machine via slapd's -h option, and advocate for setting up TLS if the user wishes to expose the DB nontheless.

5. Start and enable slapd.

This procedure is a mix of the official OpenLDAP Quickstart Guide (minus the compilation part) and the possibilities thanks to systemd and pacman. I do think it falls in line with the typical Arch-style of installing programs.

Some notes on this idea:

- I have identified the following as a sane minimal configuration. It is derived from /etc/openldap/slapd.ldif, but avoids a lot of problems. In particular, the config database is actually usable thanks to the explicit definition of a rootDN. At a minimum, everything in brackets has to be replaced.

# 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: <PASSWORD>
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbIndex: objectClass eq
# TODO: Create further indexes

- The client installation is mostly fine. - Maybe we should move the sections about creating objects and testing the installation into a basic usage section. - I would call this section "Installation" and have a separate "Configuration" section to explain some of the more useful options OLC provides. This is also where I think the TLS part should live.

It would be nice if we could have a discussion on this, as I spent the last couple of days trying to figure out how to install OpenLDAP properly due to the current explaination being rather unuseful by itself. Everything is open for discussion :) Logolive (talk) 12:58, 12 April 2021 (UTC)

Since no one seemed to complain for the past two months, I went ahead with this plan. Someone please review the changes and fix potential errors. I will delete this section in a few days, should nothing come up. Logolive (talk) 12:32, 23 June 2021 (UTC)

Shouldn't changes to the configuration be handled through root (sudo)? As in "sudo ldapmodify -Y EXTERNAL -H ldapi:///". And if we're going to add a user to the config database shouldn't they have a password assigned for that database? For that matter, shouldn't it be a different user to avoid confusion?

I spent the last two days pulling my hair out trying to get this to actually function and never did. Even using ldapi:/// didn't work as root doesn't appear to have the expected permissions (other guides presume this access to be a default.) I solved it by (and would recommend) adding an acl to the configuration database to enable root access.

# The config database
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcAccess: to * 
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage 
  by * break

For reference I was concurrently following the LDAP authentication article. I noticed the problem while attempting to add the entries for TLS from this article and couldn't. Deleting the files in /etc/openldap/slapd.d/ and /var/lib/openldap/openldap-data/ then adding the above access rule to config.ldif and starting from the beginning generated a working installation that was able to accept the ldif containing the tls information through "sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f <ldif file>". RageBanken (talk) 15:49, 26 February 2023 (UTC)

Proposal for a simple introduction to Directories

As is mentioned at the page's beginning, Directory Services are an enormous topic. However, it seems reasonable to describe the bare minimum to get people started using LDAP (possibly on another page). By minimum I mean:

• The tree-like structure of LDAP
• Schemas, what they are for and the most common ones
• Links to topics like querying an LDAP directory, but maybe mention a few example queries, to get people started.

Why? Besides providing a shallower learning curve for beginners, it would allow us to write this page on a much more professional level of language. The current page is mainly: Type this, type that, don't worry... We should at least explain, what each command does, which is much easier once we can assert a basic understanding of LDAP. Logolive (talk) 12:43, 23 June 2021 (UTC)

Tools section

The page mentions in the Next Steps section: A nice web frontend is phpLDAPadmin. And towards the end there is a reference to Apache Directory Studio.

I think we should add some sort of Utilities Section, to collect these references. Any ideas? Logolive (talk) 12:49, 23 June 2021 (UTC)