Setup Back_LDAP Proxy

Learn how to properly configure and utilize a Back_LDAP Proxy for enhanced security and authentication in your network environment.

Updated at August 9th, 2024

+ More

Table of Contents

Overview Configure the Database Section Bind with the Server Additional Configuration Options Cancel Operations Chase Referrals Connection TTL Identity Assertion Authorization Identity Assertion Passthrough Idle Timeout Keepalive Network Timeout No References Omit Unknown Schema On Error Protocol Version Rebind as User Rewrite Engine Suffix Massage Timeout TLS Configuration Summary of Key Directives Access Control Overlays Example Configurations Example 1: OpenLDAP as a Proxy to Active Directory Example 2: NSLCD Example 3: PAM LDAP Configuration Conclusion

Date: 01-17-2022
Last Updated: 08-08-2024

Overview

The LDAP backend redirects requests to another server, acting as an LDAP proxy. This allows the use of common configuration directives such as suffix, which selects the appropriate backend when a request is received by the server. Access control lists (ACLs), size and time limits, and other settings can be applied to search results.

Configure the Database Section

Modify /opt/symas/etc/openldap/slapd.conf for any authentication backend with the following connection parameters:

database ldap
Server address: ldap://ad.example.com
Bind DN: CN=Administrator,CN=Users,DC=example,DC=com 
Bind Password: AD_password
Users branch: CN=DomainUsers,DC=example,DC=com

The Server Address should be connected to the desired protocol:

uri ldap://host[:port]/
uri ldaps://host[:port]/
uri ldapi:///

Note: These entries cannot have multiple values; the last supplied value silently overrides the previous ones. The server and uri directives can contain a whitespace- or comma-separated list of values, passed to the underlying client library. The library attempts to connect to each member of the list until one succeeds.

Bind with the Server

By default, the server uses a simple bind with an empty binddn and credentials, meaning operations are performed anonymously unless otherwise set. If not configured, and if idassert-bind is defined, the latter identity is used instead.

acl-bind bindmethod=simple|sasl
[binddn=<simple DN>]
[credentials=<simple password>]
[saslmech=<SASL mech>]
[secprops=<properties>]
[realm=<realm>]
[authcId=<authentication ID>]
[authzId=<authorization ID>]
[starttls=no|yes|critical]
[tls_cert=<file>]
[tls_key=<file>]
[tls_cacert=<file>] | [tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_cipher_suite=<ciphers>]
[tls_protocol_min=<major>[.<minor>]]
[tls_crlcheck=none|peer|all]

These settings define the authentication method used internally by the proxy to collect information related to access control, especially when an operation is performed with the identity of the rootdn of the LDAP proxy database. The connection between the proxy database and the remote server is cached regardless of the lifespan of the client-proxy connection that established it.

Security Note: This identity is not implicitly used by the proxy when the client connects anonymously. The idassert-bind feature, however, can be crafted to implement this behavior, which is intrinsically unsafe and should be used with extreme care. This directive obsoletes acl-authcDN and acl-passwd. The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert, which defaults to "demand."

Additional Configuration Options

Cancel Operations

cancel {ABANDON|ignore|exop[-discover]}

This directive defines how to handle operation cancellation. By default, ABANDON is invoked, causing the operation to be abandoned immediately. If set to ignore, no action is taken and any further response is ignored. This may result in additional response messages being queued for that connection, so it is recommended that long-lasting connections be timed out using idle-timeout or conn-ttl to ensure resources are eventually released. If set to exop, a cancel operation (RFC 3909) is issued, resulting in the cancellation of the current operation; the cancel operation waits for a remote server response, so its use may not be recommended. If set to exop-discover, support of the cancel extended operation is detected by reading the remote server's root DSE.

Chase Referrals

chase-referrals {YES|no}

This directive enables or disables automatic referral chasing, which is delegated to the underlying libldap, with rebinding potentially performed if the rebind-as-user directive is used. The default is to chase referrals.

Connection TTL

conn-ttl <time>

This directive causes a cached connection to be dropped and recreated after a specified TTL (time-to-live), regardless of whether it is idle or not.

Identity Assertion Authorization

idassert-authzFrom

If defined, this directive selects which local identities are authorized to use the identity assertion feature. The string follows:

idassert-bind bindmethod=none|simple|sasl
[binddn=<DN>]
[credentials=<password>]
[saslmech=<SASL mech>]
[secprops=<properties>]
[realm=<realm>]
[authcId=<authentication ID>]
[authzId=<authorization ID>]
[starttls=no|yes|critical]
[tls_cert=<file>]
[tls_key=<file>]
[tls_cacert=<file>] | [tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_cipher_suite=<ciphers>]
[tls_protocol_min=<major>[.<minor>]]
[tls_crlcheck=none|peer|all]

This directive allows one to define the parameters of the authentication method that is internally used by the proxy to authorize connections authenticated by other databases. Direct binds are always proxied without any idassert handling. The identity defined by this directive, according to the properties associated with the authentication method, is supposed to have auth access on the target server to attributes used on the proxy for authentication and authorization, and to be allowed to authorize the users.

This requires having proxyAuthz privileges on a wide set of DNs, e.g., authzTo=dn.subtree:, and the remote server to have authz-policy set to to or both. See slapd.conf(5) for details on these statements and for remarks and drawbacks about their usage. The supported bindmethods are none|simple|sasl, where none is the default, i.e., no identity assertion is performed. The authz parameter is used to instruct the SASL bind to exploit native SASL authorization, if available. Since connections are cached, this should only be used when authorizing with a fixed identity (e.g., by means of the authzDN or authzID parameters). Otherwise, the default proxyauthz is used, i.e., the proxyAuthz control (Proxied Authorization, RFC 4370) is added to all operations.

Identity Assertion Passthrough

idassert-passthru

If defined, this directive selects which local identities bypass the identity assertion feature. These identities need to be known by the remote host.

Idle Timeout

idle-timeout <time>

This directive causes a cached connection to be dropped and recreated after it has been idle for the specified time.

Keepalive

keepalive [idle:probes:interval]

The keepalive parameter sets the values of idle, probes, and interval used to check whether a socket is alive. idle is the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes; probes is the maximum number of keepalive probes TCP should send before dropping the connection; interval is the interval in seconds between individual keepalive probes. Only some systems support customization of these values; the keepalive parameter is ignored otherwise, and system-wide settings are used.

Network Timeout

network-timeout <time>

Sets the network timeout value after which poll(2)/select(2) following a connect(2) returns in case of no activity. The value is in seconds, and it can be specified as for idle-timeout.

No References

norefs {YES|no}

If set to yes, this directive prevents search reference responses from being returned. By default, they are returned unless the request is LDAPv2.

Omit Unknown Schema

omit-unknown-schema {YES|no}

If set to yes, this directive prevents the server from returning objectClasses or attributes that are not known to the local server. The default is to return all schema elements.

On Error

onerr {CONTINUE|stop}

This directive allows the selection of behavior in case an error is returned by the remote server during a search. The default, continue, consists of returning success. If set to stop, the error is returned to the client.

Protocol Version

protocol-version {0,2,3}

This directive sets the LDAP protocol version used for communicating with the remote server. The default is version 3. You can set it to 2 if the remote server only supports LDAPv2, though this is rare and not recommended for modern configurations.

Rebind as User

rebind-as-user {YES|no}

If set to yes, the proxy will rebind using the client's bind credentials when chasing referrals. This allows the proxy to authenticate to the remote server as the original client. By default, this is set to no, meaning the proxy binds using its own credentials.

Rewrite Engine

rewriteEngine {on|off}

This directive enables or disables the rewrite engine, which can be used to manipulate DNs and search filters on the fly. This is a powerful feature, typically used in conjunction with rwm (Rewrite/remap overlay) for advanced proxy configurations.

Suffix Massage

suffixmassage <suffix> <massage>

The suffixmassage directive allows you to rewrite the suffix of a request to match the expected suffix of the remote server. This is useful when the DIT (Directory Information Tree) structure differs between the proxy and the remote server.

For example:

suffixmassage "dc=example,dc=com" "dc=remote,dc=com"

This rewrites all requests with a suffix of "dc=example,dc=com" to "dc=remote,dc=com" when sending to the remote server.

Timeout

timeout [add=<time>] [delete=<time>] [modify=<time>] [search=<time>]

This directive sets the timeout for various LDAP operations. If any operation exceeds the specified time limit, it will be terminated. You can set different timeouts for add, delete, modify, and search operations:

add=<time>: Timeout for adding entries
delete=<time>: Timeout for deleting entries
modify=<time>: Timeout for modifying entries
search=<time>: Timeout for search operations

TLS Configuration

You can configure TLS parameters specific to the LDAP backend using the following directives:

tls_cert=<file>: The TLS certificate file to use for connections to the remote server.
tls_key=<file>: The private key corresponding to the TLS certificate.
tls_cacert=<file>: The CA certificate file to verify the remote server's certificate.
tls_cacertdir=<path>: The directory containing CA certificates.
tls_reqcert=never|allow|try|demand: Specifies whether to require and verify the server's certificate. demand is the most secure, requiring verification.
tls_cipher_suite=<ciphers>: Specifies the allowed ciphers for TLS connections.
tls_protocol_min=<major>[.<minor>]: Specifies the minimum TLS protocol version to use.
tls_crlcheck=none|peer|all: Specifies whether and how to check the certificate revocation list (CRL).

Summary of Key Directives

To recap, here’s a brief summary of the most critical configuration directives for setting up a back_ldap proxy:

Server Address (uri): Defines the remote LDAP server(s) to connect to.
Bind DN & Credentials (binddn, credentials): Specifies the credentials used by the proxy to authenticate to the remote server.
Timeouts (idle-timeout, conn-ttl, network-timeout): Configures time limits for various operations and connections.
TLS Settings: Ensures secure communication between the proxy and the remote server.
Suffix Massage: Allows for DN rewriting when the DIT structure differs between the local proxy and the remote server.

Access Control

The LDAP backend does not fully honor all ACL semantics as described in slapd.access(5). Access control is typically delegated to the remote server(s).

Overlays

The LDAP backend supports many overlays for proxying functionalities:

chain: Handles referral chasing and updates through a proxy.
translucent: Allows merging of remote and local attributes.
rwm: Provides DN rewrite and attribute/objectClass mapping capabilities.

Example Configurations

Example 1: OpenLDAP as a Proxy to Active Directory

Refer to the OpenLDAP proxy documentation for Active Directory at Samba Wiki.

### Schema includes
include /opt/symas/etc/openldap/schema/core.schema
include /opt/symas/etc/openldap/schema/cosine.schema
include /opt/symas/etc/openldap/schema/inetorgperson.schema 
include /opt/symas/etc/openldap/schema/misc.schema
include /opt/symas/etc/openldap/schema/rfc2307bis.schema

## Module paths
modulepath /opt/symas/lib64/openldap/
moduleload back_ldap
# Optional
moduleload rwm

# Main settings
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

### Database definition (Proxy to AD)
database ldap
readonly yes
protocol-version 3
rebind-as-user yes
uri "ldap://{AD-Hostname/IP}:389"
suffix "{your Domain DN}"

overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map attribute mail proxyAddresses

### Logging
loglevel 0

Example 2: NSLCD

To retrieve user/groups from AD via an OpenLDAP proxy, use the following /etc/nlscd.conf:

# Mappings for Active Directory
pagesize 1000
referrals off

# Passwd
filter passwd (&(objectClass=posixAccount)(!(objectClass=computer))(uidNumber=*))
map passwd homeDirectory UnixHomeDirectory 
map passwd gecos displayName
map passwd gidNumber primaryGroupID

# Shadow
filter shadow (&(objectClass=posixAccount)(!(objectClass=computer))(uidNumber=*))
map shadow shadowLastChange pwdLastSet

# Groups
filter group (&(objectClass=posixGroup)(gidNumber=*))
map group uniqueMember member

# Local account for nslcd
uid nslcd
gid ldap

# Where is the LDAP
uri ldap://{openLDAP-Proxy-Hostname/IP}:389
base cn=Users,{your Domain DN}

# Connect-Account
binddn cn=nslcd-connect,cn=Users,{your Domain DN}
bindpw {password}

This example assumes that you've mapped the attribute "sAMAccountName" to "uid", like in the example of OpenLDAP proxy to AD above. Otherwise you have to map the attribute here. Also it is required that the user accounts have a uidNumber and the groups a gidNumber attribute.

Start the nslcd service.

Example 3: PAM LDAP Configuration

For authenticating users through an OpenLDAP proxy against AD, edit /etc/pam_ldap.conf:

base {your Domain DN}
binddn cn=nslcd-connect,cn=Users,{your Domain DN}
bindpw {password}
bind_policy soft
uri ldap://{openLDAP-Proxy-Hostname/IP}:389/
ssl no

Conclusion

Setting up a back_ldap proxy can be a powerful way to manage LDAP queries, allowing you to redirect, secure, and manipulate requests before they reach your directory servers. This approach offers flexibility in multi-directory environments, supports integration with various overlays, and can enhance the security and manageability of your LDAP infrastructure.

Carefully test each aspect of your configuration, particularly when working in production environments. If you encounter issues, consult the official OpenLDAP documentation, community forums, or your LDAP service provider for further guidance.

back_ldap proxy

Contact Us