Today's Question:  What does your personal desk look like?        GIVE A SHOUT

OpenLDAP Proxy -- slapd.conf

  sonic0002        2017-10-29 04:01:39       19,754        0    

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.

OPENLDAP  OPENLDAP PROXY  SLAPD  SLAPD.CONF 

Share on Facebook  Share on Twitter  Share on Weibo  Share on Reddit 

  RELATED


  0 COMMENT


No comment for this article.