[SSSD-users] Integrate DMZ clients (sssd) to Active Directory through proxy

[Horváth Szabolcs]

Hi,

I'd like to integrate our servers sitting in DMZ to Active Directory
(domain controllers are located inside), without direct network connection
between the parties.
The security policy says we have to use some kind of intermediate party
(e.g. layer7 proxy).

A few years ago I had a project where the clients and the proxy server were
all RHEL7, and the solution was slapd as an ldap proxy and pam_ldap+nslcd
on client side (https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD).

Time has passed, we have no longer have RHEL7s, RHEL/SUSE no longer have
openldap-servers package (although slapd in back in EPEL9) and we don't
have nslcd+pam_ldap on SLES15 anymore.
It looks like everyone prefers 389 directory server project.

RedHat has an excellent article about the problem:
https://www.redhat.com/en/blog/identity-management-systems-dmz

Basically my options are:
1. local authentication (that's the starting point from which we want to
move on)
2. connect directly to AD (there are no working layer7 proxy solutions as
far as I know, so we rejected this option)
3. expose read only AD replicas in DMZ (so-called roDCs or 389-ds -> very
complex solution, I don't want go in this direction)
4. separate AD/IdM domain in DMZ (see above, it does not reduce complexity)
5. kdcproxy - https://github.com/latchset/kdcproxy

On the client side, I would stick to sssd (SLES 15 and RHEL8+, very limited
number of older versions).

The proxy side, I tested two solutions, none of them really work:

1. slapd (from EPEL9) as an LDAPS proxy between the clients and AD. sssd (I
tested 2.5.2) detects the presence of the proxy and fails:

---
id_provider = ldap
ldap_uri = ldaps://ldapproxy.test.local
ldap_search_base = OU=TESTLAB,DC=test,DC=local
ldap_schema = AD
[...]
auth_provider = ldap
---

   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_process_result]
(0x2000): Trace: sh[0x55bb0dca1b10], connected[1], ops[0x55bb0dd0c900],
ldap[0x55bb0dbd53e0]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_entry] (0x1000):
OriginalDN: [].
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [objectClass]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [namingContexts]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedControl]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedExtension]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedFeatures]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_parse_range] (0x2000):
No sub-attributes for [supportedLDAPVersion]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_process_result]
(0x2000): Trace: sh[0x55bb0dca1b10], connected[1], ops[0x55bb0dd0c900],
ldap[0x55bb0dbd53e0]
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
   *  (2024-01-28 20:08:27): [be[test.local]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
errmsg set
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_op_destructor]
(0x2000): Operation 1 finished
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_get_rootdse_done]
(0x2000): Got rootdse
   *  (2024-01-28 20:08:27): [be[test.local]] [sdap_get_rootdse_done]
(0x2000): Skipping auto-detection of match rule
   *  (2024-01-28 20:08:27): [be[test.local]]
[sdap_get_server_opts_from_rootdse] (0x0020): ldap_rootdse_last_usn
configured but not found in rootdse!
********************** BACKTRACE DUMP ENDS HERE
*********************************

Basically we don't have so much information in rootDSE which sssd depends
on:

# ldapsearch -h 127.0.0.1 -D
"CN=_svc_ldapquery,OU=Users,OU=TESTLAB,DC=test,DC=local" -b '' -s base
'(objectclass=*)'
#
dn:
objectClass: top
objectClass: OpenLDAProotDSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

2. kdcproxy as a kerberos proxy: https://github.com/latchset/kdcproxy

The main problem is sssd can utilize krb5 for access_provider and
access_provider, but it needs separate id_provider, usually
id_provider=ldap, and it comes to my previous problem, I couldn't proxy
ldap protocol.


Do you have any suggestions for this problem that I haven't considered?

Thanks!

Szabolcs