Op 13-12-2024 om 14:25 schreef Ilias Chasapakis
forumZFD:> Dear Kees,
>
> Many thanks for sending such a detailed answer. Really helpful and I
> guess a good fit for our situation. I was worried that it?d been
> complicated as I have never played around with OpenLDAP.
There is one limitation I forgot to mention: in my config there is a
module "mr_passthru", it is required if you want to do Microsoft
LDAP_MATCHING_RULE_IN_CHAIN queries, e.g. for nested group membership
lookups: "(memberof:1.2.840.113556.1.4.1941:=CN=...) ".
Openldap does not support these by default.
If you don't need it: simply disable the module "mr_passthru" in
slapd.conf.
If you do, it gets a little more complicated. You need to add it to the
source of openldap and compile the whole thing. The source of the module
is here: https://github.com/cbueche/openldap-passthru.
Would you want to go this way, I have made a patch that can be applied
to the debian openldap source, when you then compile the package you get
the module included.
- Kees.
>
> Best
> Ilias
>
> Am 13.12.24 um 14:15 schrieb Kees van Vloten via samba:
>> Openldap-proxy is quite simple.
>>
>> On Debian install slapd, then configure /etc/ldap/slapd.conf and
>> /etc/default/slapd. The config files below allows read-only proxying
>> of the DN-subtree, it listens to ldaps (tcp/636) and also forwards as
>> ldaps to AD.
>>
>> /etc/ldap/slapd.conf:
>>
>> # Configuration to proxy subtree to AD backend
>>
>> include /etc/ldap/schema/core.schema
>> include /etc/ldap/schema/cosine.schema
>> include /etc/ldap/schema/nis.schema
>> include /etc/ldap/schema/inetorgperson.schema
>> include /etc/ldap/schema/misc.schema
>>
>> pidfile /var/run/slapd/slapd.pid
>> argsfile /var/run/slapd/slapd.args
>>
>> TLSDHParamFile /etc/ssl/certs/dhparam.pem
>> TLSCACertificateFile /etc/ssl/certs/ca.pem
>> # Enable tls by providing the server cert
>> TLSCertificateFile /etc/ssl/certs/<HOSTNAME>.crt
>> TLSCertificateKeyFile /etc/ssl/private/<HOSTNAME>.key
>>
>> # loglevel 896 = acl-processing,stat,stat2, this logs queries and
>> responses
>> #????????? -1 = enable all
>> loglevel 896
>>
>> modulepath /usr/lib/ldap/
>> moduleload? back_ldap
>> moduleload? back_meta
>> moduleload? memberof
>> moduleload? mr_passthru
>>
>> # Per database settings
>> database meta
>>
>> readonly yes
>> protocol-version 3
>> chase-referrals no
>> sizelimit 1000
>> suffix "<AD_BASE_DN>"
>>
>> uri "ldaps://<FQDN-AD-DC-1>/<AD_BASE_DN>"
"<FQDN-AD-DC-2>"
>>
>> # It turns out we cannot limit:
>> #?? - what is in a query (i.e. restrict it to a certain pattern)
>> #?? - the bind-dn to a dn.subtree
>>
>> # We can limit what is returned, i.e. only objects (users) from these
>> dn.subtrees,
>> #?? other output of a filter is silently dropped
>> access to dn.subtree="<DN-TO-WITH-READ-ACCESS>"
>> ??? by users read
>> ??? by * none
>>
>> /etc/default/slapd:
>>
>> SLAPD_USER="openldap"
>> SLAPD_GROUP="openldap"
>> SLAPD_PIDFILE>> SLAPD_SERVICES="ldaps:///"
>> SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
>> SLAPD_OPTIONS=""
>>
>> I am using this for LDAP queries from my DMZ. It needs just one open
>> port (tcp/636) and limits ldap-queries to permissions setup in
>> slapd.conf (read on dn-subtree). That prevents unwanted open ports
>> and the ability to enumerate the whole ldap-tree of AD from the DMZ.
>> As you can see in the comment in slapd.conf, you can define the
>> service-user-dn outside of the defined filter scope access, which is
>> kind of a nice 'feature'.
>>
>> - Kees.
>