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

[Sumit Bose]

Am Sun, Jan 28, 2024 at 08:30:24PM +0100 schrieb 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
>  ********************************* 
Hi,

can you set `debug_level = 9` in the [domain/...] section of sssd.conf,
restart SSSD, try a user lookup and send the logs again? The missing
rootDSE attribute should not cause a general failure.

bye,
Sumit

>  
>  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 
>  --
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Szabolcs Horvath]

Hi Sumit,

My bad. Nscd caching was mis-directed me.

If anyone reads this thread, a working PoC looks like this:

#### SLAPD config: https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD

##### Client (SSSD) configuration

[sssd]
config_file_version = 2
debug_level = 3
domains = test.local
services = nss, pam, ifp

[nss]
filter_groups = root
filter_users = root

[pam]

[domain/test.local]
debug_level = 3
id_provider = ldap
cache_credentials = True
ldap_uri = ldaps://ldapproxy.test.local
ldap_search_base = OU=TESTLAB,DC=test,DC=local
ldap_schema = AD
ldap_default_bind_dn = CN=_svc_ldapquery,OU=Users,OU=TESTLAB,DC=test,DC=local
ldap_default_authtok = xxxxx
ldap_default_authtok_type = password
ldap_tls_cacert = /etc/openldap/certs/cert.crt
ldap_id_mapping = True
enumerate = True

fallback_homedir = /home/%u
default_shell = /bin/bash

sudo_provider = ldap
auth_provider = ldap
autofs_provider = ldap
resolver_provider = ldap

use_fully_qualified_names = False
access_provider = simple
simple_allow_groups = linux_admins
subdomain_inherit = ignore_group_members
ignore_group_members = True
ad_enable_gc = false

Sure you have to do usual things like activate pam (in case of SUSE: /usr/sbin/pam-config
--add --sss --mkhomedir), disabling nscd caching, configure nsswitch.conf (files sss).

Hope this helps.

Szabolcs