Table of Contents |
---|
(This article is work in progress)
...
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
Nested Groups
Following diagram represents a nested groups structure used for testing
In the above diagram we have OU=data which has multiple nested groups (2 levels) and we have a user 'jerry' who belongs to the final group datascience-b explicitly, but implicitly belongs to all the other groups that nest it (i.e. datascience-a and datascience)
When SSSD is properly configured (as explained later in the post) we get the following results
Code Block |
---|
# 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)
Code Block |
---|
Groups: [datascientist-a, datascientist-b, engineer, datascientist] |
Nested OUs
Following diagram shows the nested OU structure used for testing
In this example we can see that the user kim is part of group 'processors' which is part of OU processing which is part of OU data which in turn is part of OU groups.
Following is the output of 'id' command, here we can see that our user kim and group that user belongs to are retrieved correctly.
Code Block | ||
---|---|---|
| ||
# 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)
Code Block |
---|
Groups: [processors] |
This demonstrates that Knox can authenticate and retrieve groups against nested OUs.
Setup Overview
Following diagram shows a high level set-up of the components involved.
...
- Supports TLS or SSL
- 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).
- 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)
Copy the public CA certs needed to talk to LDAP at /etc/openldap/certs
To configure sssd you can use the following 'authconfig' command
Code Block | ||
---|---|---|
| ||
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.
An Following is an example of sssd.conf file
Code Block | ||
---|---|---|
| ||
[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:
- ldap_schema = rfc2307bis - Needed if all groups are to be returned when using nested groups or primary/secondary groups.
- ldap_tls_cacertdir = /etc/openldap/certs - certs to talk to LDAP server
- ldap_id_use_start_tls = True - Secure communication with LDAP
- ldap_group_nesting_level = 5 - Enable group nesting up-to 5 levels
NOTE: You might need to add / change some options in sssd.conf file to suite your needs. like debug level etc. After updating just restart the service and changes should be reflected.
Some additional settings that can be used to control caching of credentials by SSSD are
cache_credentials | Boolean | Optional. Specifies whether to store user credentials in the local SSSD domain database cache. The default value for this parameter is false . Set this value to true for domains other than the LOCAL domain to enable offline authentication. |
entry_cache_timeout | integer | Optional. Specifies how long, in seconds, SSSD should cache positive cache hits. A positive cache hit is a successful query. |
Test SSSD is configuration
To check whether SSSD is configured correctly you can use the standard 'getent' or 'id' commands
Code Block | ||
---|---|---|
| ||
$ getent passwd <ldap_user>
$ id -a <ldap_user> |
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
Code Block |
---|
<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