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