You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

(This article is work in progress)

Apache Knox provides HTTP Basic authentication against LDAP store. Knox ships with Apache Shiro authentication provider for LDAP which makes the configuration a lot easier and flexible. However there in one limitation, currently only single Organizational Unit (OU) is supported and nested OUs are not supported by Knox, using default realm – KnoxLdapRealm (KNOX-536) . Knox 0.10.0 onwards, Knox supports Linux PAM authentication provider (KNOX-537). This blog post discusses a way to set up LDAP authentication against nested OUs for Knox using PAM support provided by Knox and Linux SSSD daemon.

Some of the advantages of using this are:

  • Supported for nested OUs and nested groups

  • Faster lookups

  • Support more complex LDAP queries

  • Reduce load on the LDAP/AD server (caching by SSSD)

Setup Overview

Following diagram shows a high level set-up of the components involved.

 

 

 

Following are the component versions for this test

  • OpenLDAP - 2.4.40
  • SSSD - 1.14.1
  • Apache Knox - 0.10.0

 

LDAP

In order to support nesting of groups LDAP needs to support RFC 2307bis schema. For SSSD to talk to LDAP it has to be secure. Acquire a copy of the public CA certificate for the certificate authority used to sign the LDAP server certificate, you can test the certificate using the following openssl test command

openssl s_client -connect <ldap_host>:<ldap_port> -showcerts -state -CAfile <path_to_ca_directory>/cacert.pem

SSSD

SSSD is stricter than pam_ldap. In order to perform an authentication, SSSD requires that the communication channel be encrypted. This means that if sssd.conf has ldap_uri = ldap://<server>, it will attempt to encrypt the communication channel with TLS (transport layer security). If sssd.conf has ldap_uri = ldaps://<server>, then SSL will be used instead of TLS. This requires that the LDAP server

  1. Supports TLS or SSL
  2. Has TLS access enabled on the standard LDAP port (636) (or alternate port, if specified in the ldap_uri or has SSL access enabled on the standard LDAPS port (or alternate port).
  3. Has a valid certificate trust (can be relaxed by using ldap_tls_reqcert = never,  but it is a security risk and should ONLY be done for development and demos)

Following is an example of sssd.conf file

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, autofs
domains = default

[nss]
reconnection_retries = 3
homedir_substring = /home

[pam]
reconnection_retries = 3

[domain/default]
access_provider = ldap
autofs_provider = ldap
chpass_provider = ldap
cache_credentials = True
ldap_schema = rfc2307bis

id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://<ldap_host>/

ldap_tls_cacertdir = /etc/openldap/certs
ldap_id_use_start_tls = True

# default bind dn
ldap_default_bind_dn = cn=admin,dc=apache,dc=org
ldap_default_authtok_type = password
ldap_default_authtok = my_pasword
ldap_search_base = dc=apache,dc=org

# For group lookup
ldap_group_member = member

# Enable nesting 
ldap_group_nesting_level = 5

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

 

 

Caveats

  • For nested group membership SSSD and LDAP should use rfc2307bis schema

  • SSSD requires SSL/TLS to talk to LDAP

 

  • No labels