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
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:
- 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:
- 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
- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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
sssd-users@lists.fedorahosted.org
-
Horváth Szabolcs -
Sumit Bose -
Szabolcs Horvath