[Samba] RODC in DMZ

[Kees van Vloten]

Op 13-12-2024 om 13:26 schreef Ilias Chasapakis forumZFD via samba:
> Der Rowland,
>
> We share that concerns actually and of course if there is a way to 
> avoid it, it is always better. Another fellow suggested us an 
> LDAP-Proxy instead (personally have never setup one). What we actually 
> need in our case scenario, is only that service and not the rest of 
> bells and whistles of an RODC.

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.

>
> I just was wondering if someone had experience with what happens if 
> one does actually close some of these ports which in the end are 
> unused (of course join and replication should also be able to go on). 
> The implications of opening anything on a DMZ to an internal network 
> are for sure not nice (even with very restricted accesses) unless 
> compromises are needed for practical reasons.
>
> Thanks for sharing your thought on this.
>
> Best
> Ilias
>
> Am 13.12.24 um 11:53 schrieb Rowland Penny via samba:
>> Well, personally, I wouldn't put anything to do with AD into a DMZ, but
>> that is probably just me. Any AD client in a DMZ (and that includes an
>> RODC) must 'talk' to an internal DC.
>>
>> If you must do this, Microsoft has documentation here:
>>
>> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd728034(v=ws.10)?redirectedfrom=MSDN 
>>
>>
>> Rowland
>>
>>