Page History

...

(This article is work in progress)

Apache Knox provides HTTP Basic authentication against LDAP store. Knox ships with has always had LDAP based authentication through the Apache Shiro authentication provider for LDAP which makes the configuration a lot bit easier and flexible. However there in one limitation, currently only are a number of limitations with the KnoxLdapRealm (KNOX-536), for instance only a single Organizational Unit (OU) is supported and nested OUs are not supported by Knox, using default realm – KnoxLdapRealm (KNOX-536) . currently supported. Group lookup will not return the groups that are defined within the tree structure below that single OU. Also, group memberships that are indirectly defined through membership in a group that is itself a member of another group are not resolved. In Apache Knox 0.10.0 onwards, Knox supports Knox introduced the ability to leverage the Linux PAM authentication provider (mechanism. KNOX-537) added a KnoxPAMRealm to the Shiro provider for PAM support. This blog post discusses a way how to set up LDAP authentication against nested OUs for Knox using using the new PAM support provided by Knox and Linux SSSD daemonwith Linux SSSD daemon  and some of the advantages and key features of SSSD.

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)

Scenarios

There are two scenarios that were tested

• Nested groups
• Nested OUs
• Using Multiple Search Bases

Nested Groups

Following diagram represents a nested groups structure used for testing

...

# id -a jerry
uid=4001(jerry) gid=4000(engineer) groups=4000(engineer),5000(datascientist),6000(datascientist-a),7000(datascientist-b)

...

When we try to access a resource secured by Knox using the user jerry we can see all the groups that user jerry belongs to are logged in gateway-audit.log (part of Knox logging)

Groups: [datascientist-a, datascientist-b, engineer, datascientist]

Nested OUs

Following diagram shows the nested OU structure used for testing

...

# id -a kim
uid=8001(kim) gid=8000(processors) groups=8000(processors)

Similarly, when we try to access a resource secured by Knox using the user kim we get the following entry in gateway-audit.log (part of Knox logging)

...

This demonstrates that Knox can authenticate and retrieve groups against nested OUs.

Using Multiple Search Bases

Following diagram shows nested parallel OUs (processing and processing-2)

Image Added

In this test we will configure two different search bases 

• ou=processing,ou=data,ou=groups,dc=hadoop,dc=apache,dc=org
• ou=processing-2,ou=data,ou=groups,dc=hadoop,dc=apache,dc=org

sssd.conf settings (relevant) for this test are as follows:

[sssd]
....
domains = default, processing2
....

[domain/default]
....
ldap_search_base = ou=processing,ou=data,ou=groups,dc=hadoop,dc=apache,dc=org
....

[domain/processing2]
....
ldap_search_base = ou=processing-2,ou=data,ou=groups,dc=hadoop,dc=apache,dc=org
....

To check whether SSSD correctly picks up our users we use the id command

# id kim
uid=8001(kim) gid=8000(processors) groups=8000(processors)

# id jon
uid=9001(jon) gid=9000(processors-2) groups=9000(processors-2)

Similarly, when we try to access a resource secured by Knox using the user kim and jon we get the following entry in gateway-audit.log (part of Knox logging)

for kim
success|Groups: [processors]

for jon
success|Groups: [processors-2]

Also, if you take out 'processing2' service from sssd.conf file and restart sssd, user 'jon' will not be found but 'kim' can still be found:

# id jon
id: 'jon': no such user
# id kim
uid=8001(kim) gid=8000(processors) groups=8000(processors)

Thanks to Eric Yang for pointing out this scenario.

Setup Overview

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

...

• 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

...

authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldapauth --ldapserver=<ldap_host> --enableldaptls --ldapbasedn=dc=my-company,dc=my-org --enableshadow --enablerfc2307bis --enablemkhomedir --enablecachecreds --update

...

After the command executes you can see that sssd.conf file has been updated.

...

[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]

The important settings to note are:

...

Test SSSD is configuration

To check whether SSSD is configured correctly you can use the standard 'getent' or 'id' commands

...

Using the above commands you should be able to see all the groups that <ldap_user> belongs to. If you do not see the secondary groups check the 'ldap_group_nesting_level = 5' option and adjust it accordingly.

Knox

Setting up Knox is relatively easy, install Knox on the same machine as SSSD and update the topology to use PAM based auth 

			<param>
                <name>main.pamRealm</name> 
                <value>org.apache.hadoop.gateway.shirorealm.KnoxPamRealm</value>
            </param>
            <param>
                <name>main.pamRealm.service</name> 
                <value>login</value>
            </param>

For more information and explanation on setting up Knox see the PAM Based Authentication section in Knox user guide.

Caveats

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

• SSSD requires SSL/TLS to talk to LDAP

Troubleshooting