IPFire 3.x has support for a central user database that is managed by the administrator and can be used for all services that can access LDAP.
On these pages, we want to discuss and point out how we do this.
Integration of the server software itself. We will use OpenLDAP (http://www.openldap.org/) for this purpose, because it is a fast and reliable server, that is easy to manage and has proven to work.
This is almost done - i.e. package is compiled and a tested configuration is available.
Currently there is no automatically or GUI based configuration available.
A point to focus on is the integration if the schemas that will be integration right from the start. Esp. regarding support for samba and more complex software that needs new attributes.
A MUST is: core, cousine and inetOrgPerson.
At default the server is listening on a local unix socket on "/run/ldapi". So it is only available on the local system. If there is the need to access the server from a remote host, there is support for TLS/SSL implemented and automatically will be started.
The required certificates currently have to be created by running a script stored in "/usr/share/openldap/".
It generates a self-signed certificate and puts it to the correct place to use with openldap.
Internal format for the database is hdb, because it is the most advanced one and has more features than bdb like renaming a subtree and a better performance.
There is no need to configure the LDAP modules directory, because the required "hdb" backend module is statically linked into the binary.
An other nice backend "monitor" has also linked statically - the benefit is we don't have to take care of the modules path "/usr/lib/openldap" or "/usr/lib64/openldap" for a standard IPFire and single LDAP installation.
No sensitive information should be readable by default. So it is important to have very strict ACLs.
Insert more about this, here...
unique, memberOf, refint and contraint seem to be overlays that can make work very easy .
accesslog and syncprov should be activated when we use replication.
OpenLDAP is configured to use the new configuration shema and layout, based on ldif files which can do changes during runtime without any need of restarting the LDAP server anymore.
The template for the default configuration is stored in "/usr/share/openldap/openldap-conf.ldif".
When server has been set up correctly, we need to make it usable by the system.
Users should be able to authenticate on the console with their credentials when they have rights for administration. Other users should be not allowed.
Shadow has no support for neither PAM nor LDAP and should only be used to create system accounts. Don't touch that.
libuser is the tool that will create, modify and delete accounts on the DIT. So configuration is needed.
Search help on Google
To setup the LDAP server copy the config template from "/usr/share/openldap/openldap-conf.ldif" to "/tmp" and change the "@SUFFIX@" to something like "dc=blah,dc=de".
The next step is to push the configuration. Do this by using the following command:
slapadd -F /etc/openldap/slapd.d/ -n0 -l yourfile.ldif
chown -R ldap:ldap /etc/openldap/slapd.d/
systemctl start openldap.service
Grab the IPFire-DIT with git. (git://git.ipfire.org/ipfire.org.git)
Generate the "dit" by using make and put the "template.ldif" to "/usr/share/ipfire-dit/". Install it with the following command:
bash install.sh blah.de -p yourpassword
Install sssd and sssd-clients with pakfire.
Edit the "/etc/sssd/sssd.conf" and replace the @SUFFIX@ to your configured LDAP domain and add the following line in your LDAP section:
ldap_tls_reqcert = never
ldap_uri = ldaps://localhost
systemctl start sssd.service
modules = ldap create_modules = ldap
[ldap] # Setting these is always necessary. server = ldapi:// basedn = dc=blah,dc=de # Setting these is rarely necessary, since it's usually correct. userBranch = ou=People groupBranch = ou=Group # Set only if your administrative user uses simple bind operations to # connect to the server. binddn = cn=admin,dc=blah,dc=de # Set this only if the default user (as determined by SASL) is incorrect # for SASL bind operations. Usually, it's correct, so you'll rarely need # to set these. user = admin authuser = admin