In the introductory post of OpenLDAP proxy, we mentioned that slapd.conf is the configuration file which tells the slapd service what to do. Apart from this, there is a dynamic way of configuring slapd where the configurations are stored in LDIF database. In the future, LDIF database will be the one for configuring slapd, the old style of slapd.conf is deprecated. The slapd.conf can be converted to LDIF style using the slapdtest command.
slapdtest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d
For demonstration purpose, we will use slapd.conf to explain how to configure the slapd service as an OpenLDAP proxy. And we will explain the one which has meta backend configured here. The ldap backend configuration is similar to that of meta backend with some minor differences.
Below is a working sample configuration of OpenLDAP proxy.
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Include schemas include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time modulepath /usr/lib/openldap modulepath /usr/lib64/openldap moduleload back_meta moduleload rwm # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running. TLSCACertificateFile /root/openldap_proxy/data/certs/ldap.crt TLSCertificateFile /root/openldap_proxy/data/certs/ldap.crt TLSCertificateKeyFile /root/openldap_proxy/data/certs/ldap.key # Log level loglevel 256 ####################################################################### # database definitions ####################################################################### #### Database definition ######################################### database meta suffix "dc=test,dc=com" rootdn "cn=admin,dc=test,dc=com" rootpw "password" uri "ldap://192.168.56.100/dc=test,dc=com" readonly yes lastmod off suffixmassage "dc=test,dc=com" "dc=ou1,dc=test,dc=com" uri "ldap://192.168.56.101/dc=test,dc=com" readonly yes lastmod off suffixmassage "dc=test,dc=com" "dc=ou2,dc=test,dc=com" idassert-bind bindmethod=simple binddn="cn=admin,dc=test,dc=com" credentials="password" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=admin,dc=test,dc=com" overlay rwm rwm-map attribute uid sAMAccountName
This is a standard slapd.conf file which contains declarations of schemaes and other general settings. We will only focus the settings that are proxy specific.
moduleload back_meta
This loads the meta backend module so that meta backend can be used
database meta
This declares the backend of the LDAP server, it is meta in this case. ldap can be set as well.
suffix "dc=test,dc=com"
This declares the virtual naming context(base) the LDAP client can use to search the LDAP proxy. It can be any meaningful value conforming to the base syntax
rootdn "cn=admin,dc=test,dc=com"
rootpw "password"
These two entries declare the virtual bind dn and password the LDAP client can use to authenticate to the LDAP proxy. These are useful when the remote LDAP server needs client bind because we need to tell the proxy who can authenticate to the remote LDAP server.
uri "ldap://192.168.56.100/dc=test,dc=com"
This starts a new remote LDAP server entry. The syntax should be "://[:]/<vritual-naming-context/suffix>". The virtual-naming-context at the end of the uri is usually the same as the suffix declared after database meta.
Every new remote LDAP server should use a separate uri.
suffixmassage "dc=test,dc=com" "dc=ou1,dc=test,dc=com"
This declares the mapping between the defined suffix/base in the proxy and the real base in the remote LDAP server so that it could redirect the query to the real remote LDAP server's search base when a client query comes in. The left part is the virtual-naming-context which is usually the same as the suffix declared after the database meta. The right part is the real search base in the remote LDAP server.
This is not available for ldap backend.
readonly yes
This declares that the LDAP client can only query the remote LDAP server but cannot update the remote LDAP server. This would be what we will do usually when using LDAP server as a proxy.
lastmod off
This also tells that the remote server cannot be modified. The default value is off which will not allow modification.
idassert-bind bindmethod=simple
binddn="cn=admin,dc=test,dc=com"
credentials="password"
mode=none
flags=non-prescriptive
idassert-authzFrom "dn.exact:cn=admin,dc=test,dc=com"
These are needed when the remote LDAP server needs client authentication to be able to query the server. There are a few bindmethods supported. One is simple which needs normal dn and password for authentication. The binddn and credential should be provided by the real LDAP server.
Also the authzFrom declares what local identities can access the identity assertion feature. In this case, we defined that cn=admin,dc=test,dc=com can access it. This is the rootdn defined in the proxy.
overlay rwm
rwm-map attribute uid sAMAccountName
This defines the mapping between the attribute name the proxy server exposes to client and the real attribute name provided by the remote LDAP server. This is useful when different remote LDAP servers may have different attribute names which mean the same thing. For example, in a Linux LDAP server, uid would mean the user id, while in Windows AD, the same thing may be represented by sAMAccountName. Or they are useful when customized attribute are desired.
In next post, we would introduce how to set up the LDAP proxy using slapd.conf.
