In Part 2 of 4 – SSSD Linux Authentication: LDAP Identity Store Requirements all the aspects of the LDAP Identity Store requirements were covered. And before that in article Part 1 of 2 - SSSD Linux Authentication: Introduction and Architecture I covered an introduction and high-level architecture of SSSD, which will be very important for this article. Finally, in Part 3, I will cover all the necessary steps to implement SSSD in order to support the goals pointed out in Part 1 of 4 - SSSD Linux Authentication: Introduction and Architecture. I would review each step carefully before implementing it so that you fully understand the reason for each step.
The following steps walk you through implementing SSSD and configuring SSSD. Most of everything are examples you will need to extrapulate to fit your own deployment.
Your Linux server may or may not have SSSD already installed. The following show steps in determining if SSSD is already installed and if not how to install the package.
To determine if SSSD is installed run the following command as root.
[root@myhost] yum list installed | grep sssd
python-sssdconfig.noarch 1.13.3-56.el6 @public_ol6_latest
sssd.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-ad.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-client.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-common.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-common-pac.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-ipa.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-krb5.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-krb5-common.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-ldap.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-proxy.x86_64 1.13.3-56.el6 @public_ol6_latest
If you get the above list of packages you should be good, if not, go to the next step.
If you don’t see anything from the previous step, then run the following command as root to install SSSD. Once it is installed you can run the same command from the previous step to review and be certain the SSSD packages are installed.
[root@myhost] yum –y install sssd sssd-client
TIP: The sssd-tools package is an option you can install by running “yum –y install sssd-tools”. This utility can be used to provide various functions to create, modify, or delete a user and groups among other useful things. |
Next the Linux server /etc/nsswitch.conf needs to be configured to retrieve Posix attributes from the LDAP servers.
As root make a backup of nsswitch.conf
[root@host ] cp /etc/nsswitch.conf /etc/ORIG_nsswitch.conf
As root use a text editor like vi to configure /etc/nsswitch.conf
[root@host ] vi /etc/nsswitch.conf
Make the specific configuration changes per the table below, then save /etc/nsswitch.conf, and exit the file.
Original | Update |
passwd: files shadow: files group: files services: files netgroup: nisplus automount: files nisplus | passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss automount: files sss |
###############################
# Example sssd.conf:
#
#
# /etc/nsswitch.conf
#
passwd: files sss
shadow: files sss
group: files sss
sudoers: files sss
#hosts: db files nisplus nis dns
hosts: files dns
#
# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
#
bootparams: nisplus [NOTFOUND=return] files
#
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
#
netgroup: files sss
#
publickey: nisplus
automount: files sss
You will need to run the following command as root to enable SSSD.
[root@host] authconfig --update --enablesssd --enablesssdauth
As mentioned earlier, SSSD requires encrypted communication over the LDAP protocol using a TLS certificate. It is out of the scope of this article to provide the steps to configure certificates on the LDAP identity stores, so I will make the assumption that the identity LDAP store already has TLS certificates installed and working. To make sure, LDAPS can be verified in a couple steps.
For troubleshooting purposes and also to help verify users in LDAP, it is advised to install openldap-clients on your Linux server if needed. If you already have ldapsearch installed you can skip this step.
Run the following command to see what package needs to be installed to provide ldapsearches.
[root@myhost] yum whatprovides */ldapsearch
You should get something returned and maybe the last one is similar to this.
[root@myhost]
openldap-clients-2.4.19-15.el6.x86_64 : LDAP client utilities
Repo : public_ol6_latest
Matched from:
Filename : /usr/bin/ldapsearch
Now run the following to install openldap-clients:
[root@myhost] yum -y install openldap-clients
As root login on the Linux server you installed SSSD, use openssl and run the following command to return the LDAP server TLS certificate (modify to your LDAP server hostname and port). This will return a long response that includes details of the certificate and the actual certificate within the headings; -----BEGIN CERTIFICATE----- and -----END CERTIFICATE--------.
[root@host] openssl s_client \
-connect my.ldaphost.com:1389 -showcerts </dev/null
Below is an example response --
[caption id="attachment_47826" align="aligncenter" width="948"] Example certificate response[/caption]
Now copy the certificate that was returned running the openssl command and save it as some name; e.g. oid.cert.pem. Note the location does not necessarily have to be under /etc/openldap/cacerts. However, the correct permissions are required and the location reference can be defined in the sssd.conf file later.
[root@host] cd /etc/openssl/cacerts
[root@host] vi oid.cert.pem
<Enter “i” for insert> and paste in the cert retrieved previously
[caption id="attachment_47828" align="aligncenter" width="900"] Example insert x509 cert[/caption]
<Hit esc and enter colon “:” wq to write and quite> (This is standard vi).
As root check the TLS certificate by running the following openssl command.
[root@host] openssl x509 -text -in oid.cert.pem
As root apply the proper ownership and permissions to the TLS certificate; modify the path if your certificates will be in a different location.
[root@host] chown root:root /etc/openldap/cacerts/oid.cert.pem
[root@host] chmod 644 /etc/openldap/cacerts/oid.cert.pem
[root@host] ls -l /etc/openldap/cacerts/oid.cert.pem
-rw-r--r--. 1 root root 985 May 3 15:03 /etc/openldap/cacerts/oid.cert.pem
Using the openldap version of ldapsearch run any of the following commands to verify LDAPS works. You should get a response that returns the base of your LDAP server. The first command uses LDAPS over the TLS port 636, and the second command tries TLS over the open port 389. You may need to see what options to use if your ldapsearch version is different.
[root@host] ldapsearch -x -H ldaps://my.ldap.com:636 –b "dc=oracle,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=oracle,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
#
# search result
search: 2
result: 48 Inappropriate authentication
text: Server is Configured to Deny Anonymous Binds
#
# numResponses: 1
OR
[root@host] ldapsearch -x -Z -h ldap://my.ldap.com -p 389 -b "dc=oracle,dc=com"
ldap_start_tls: Operations error (1)
# extended LDIF
#
# LDAPv3
# base < dc=oracle,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
#
# search result
search: 3
result: 48 Inappropriate authentication
text: Server is Configured to Deny Anonymous Binds
#
# numResponses: 1
Since SSSD requires all communication over LDAP to be TLS, the prior steps need to be repeated for each LDAP identity source that SSSD will be configured whether that termination point be a LDAP server or load balancer.
The topic on whether you install Microsoft Identity Management for UNIX was already explained in the Pre-Install Guideline Overview section. If you do need this package installed, follow the instruction from Microsoft here https://msdn.microsoft.com/en-us/library/cc731178(v=ws.11).aspx.
The heart of SSSD configuration is in the sssd.conf located under /etc/sssd. There are many parameters that can be used such as https://linux.die.net/man/5/sssd-ldap and https://linux.die.net/man/5/sssd-ad. The parameters used in this article are more specific to authenticating a user using a password stored in a LDAP server, and authorizing a user with groups also stored in a LDAP server, but SSSD certainly provides more features though that is out of scope.
Run the following command to prepare a sssd.conf file.
[root@myhost] cd /etc/sssd
[root@myhost] touch sssd.conf
[root@myhost] chmod 0600 sssd.conf
[root@myhost] vi sssd.conf
The following table will provide the necessary parameters with examples. Your final sssd.conf should look similar depending on whether you are using multiple LDAP servers or also use Active Directory with the exception of any adjustments to the values per your environment.
SSSD [sssd] -
Parameter | Value | Description |
config_file_version | 2 | SSSD 0.6.0 and later use version 2 |
reconnection_retries | 3 | Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up. |
sbus_timeout | 30 | |
services | nss, pam, autofs | Comma separated list of services that are started when sssd itself starts. |
domains | OID, AD | List of domains in the order you want them to be queried. |
Example:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, autofs
domains = OID, AD
Option 2 – Using SSSD ldap_id_mapping to Active Directory objectSid
Use the following additional configurations if you decide to leverage SSSD’s id mapping feature that will dynamically generate a uid number for a user and assign a primary group along with a home directory and default shell.
NSS [nss] -
Parameter | Value | Description |
reconnection_retries | 3 | Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up. |
debug_level | 2 | Bit mask that indicates which debug levels will be visible; 9 is the highest. |
Example:
[nss]
reconnection_retries = 3
debug_level = 2
PAM [pam] -
Parameter | Value | Description |
reconnection_retries | 3 | Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up. |
debug_level | 2 | Bit mask that indicates which debug levels will be visible; 9 is the highest. |
Example:
[pam]
reconnection_retries = 3
debug_level = 2
Use the following parameters if you are using Active Directory, but pay attention to option 1 and 2 sections of this configuration and decide which is best for you based on comments made earlier on this topic.
[domain/AD] -
Parameter | Value | Description |
description | AD 2012R2 DC | This section is only a label. |
debug_level | 2 | Bit mask that indicates which debug levels will be visible; 9 is the highest. |
enumerate | true | Determines if a domain can be enumerated; true, users and groups are enumerated. |
min_id | 1000 | UID and GID limits for the domain. |
id_provider | ldap | The identification provider used for the domain. |
auth_provider | ldap | The authentication provider used for the domain. |
ldap_schema | rfc2307bis | Specifies the Schema Type in use on the target LDAP server. |
cache_credentials | true | Determines if user credentials are also cached in the local LDB cache |
ad_server | cloud.acme.com | |
ldap_search_base | dc=my,dc=acme,dc=com | The default base DN to use for performing LDAP user operations. |
ldap_default_bind_dn | cn=sssd_bind,cn=Users, dc=my,dc=acme,dc=com | The default bind DN to use for performing LDAP operations. |
ldap_default_authtok_type | password | The type of the authentication token of the default bind DN. |
ldap_default_authtok | <bind password> | The authentication token of the default bind DN. Only clear text passwords are currently supported. |
ldap_tls_reqcert | allow | Specifies what checks to perform on server certificates in a TLS session, if any. |
ldap_tls_cacertdir | /etc/openldap/certs | Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. |
ldap_user_object_class | user | The object class of a user entry in LDAP. |
ldap_user_name | sAMAccountName | The LDAP attribute that corresponds to the user's login name. |
ldap_user_principal | userPrincipalName | The LDAP attribute that contains the user's Kerberos User Principal Name (UPN). |
ldap_group_object_class | group | The object class of a group entry in LDAP; default posixGroup. |
ldap_group_name | cn | The LDAP attribute that corresponds to the group name. |
ldap_group_gid_number | gidNumber | The LDAP attribute that corresponds to the group's id. |
ldap_force_upper_case_realm | true | Some directory servers, for example Active Directory, might deliver the realm part of the UPN in lower case, which might cause the authentication to fail. |
Option 1 – Using Microsoft Identity Management for UNIX schema extension
Use the following additional configurations if you decide to install Microsoft Identity Management for UNIX schema extension.
[domain/AD] -
Parameter | Value | Description |
ldap_id_mapping | false | Specifies that SSSD should attempt to map user and group IDs. |
ldap_user_uid_number | uidNumber | The LDAP attribute that corresponds to the user's id. |
ldap_user_gid_number | gidNumber | The LDAP attribute that corresponds to the user's primary group id. |
ldap_group_gid_number | gidNumber | The LDAP attribute that corresponds to the group's id. |
ldap_user_home_directory | unixHomeDirectory | The LDAP attribute that contains the name of the user's home directory, this can be modified per your environment. |
ldap_user_shell | loginShell | The LDAP attribute that contains the path to the user's default shell, this can be modified per your environment. |
Option 2 – Using SSSD ldap_id_mapping to Active Directory objectSid
Use the following additional configurations if you decide to leverage SSSD’s id mapping feature that will dynamically generate a uid number for a user and assign a primary group along with a home directory and default shell.
[domain/AD] -
Parameter | Value | Description |
ldap_id_mapping | true | Specifies that SSSD should attempt to map user and group IDs. |
ldap_user_objectsid | objectSid | The LDAP attribute that contains the objectSID of an LDAP user object stored in Active Directory. |
ldap_group_objectsid | objectSid | The LDAP attribute that contains the objectSID of an LDAP group object stored in Active Directory. |
ldap_user_primary_group | primaryGroupID | Active Directory primary group attribute for ID-mapping. Note that this attribute should only be set manually if you are running the “ldap” provider with ID mapping. |
case_sensitive | false | New option that allows to treat names in a case insensitive manner. This option is set to "true" by default, maintaining the POSIX standard setting. |
fallback_homedir | /home/%d/%u | et a default template for a user's home directory, this can be modified per your environment. |
default_shell | /bin/bash | The LDAP attribute that contains the path to the user's default shell, this can be modified per your environment. |
Example:
[domain/AD]
# AD General
description = AD 2012R2 DC
debug_level = 2
enumerate = true
min_id = 1000
#
# AD Providers
id_provider = ldap
auth_provider = ldap
#
# AD LDAP General
ldap_schema = rfc2307bis
cache_credentials = true
ldap_id_mapping = false
#
# AD LDAP Connection Settings
ad_server = my.acme.com
ldap_search_base = dc=my,dc=acme,dc=com
ldap_uri = ldaps://cloud.acme.com
ldap_default_bind_dn = cn=sssd_bind,cn=Users,dc=my,dc=acme,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = Oracle123
#
# AD Use below if you are using SSL/TLS
#ldap_id_use_start_tls = true
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/certs
#
# AD LDAP Objectclass Mappings
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = cn
ldap_force_upper_case_realm = True
#
# Uncomment the configurations of one of the options you decide to use.
# OPTION 1 – Microsoft Idm for UNIX
#ldap_user_uid_number = uidNumber
#ldap_user_gid_number = gidNumber
# ldap_group_gid_number = gidNumber
#ldap_user_home_directory = unixHomeDirectory
#ldap_user_shell = loginShell
#
# OPTION 2 – SSSD id_mapping
#ldap_user_objectsid = objectSid
#ldap_group_objectsid = objectSid
#ldap_user_primary_group = primaryGroupID
#case_sensitive = false
#ldap_id_mapping = true
#fallback_homedir = /home/%d/%u
#default_shell = /bin/bash
The following table should work for other LDAP servers like OID, OUD, ODSEE, etc. If you use multiple LDAP servers be sure to name the [domain/<ldap>] section appropriately. Below is an example, but it could also be [domain/LDAP], [domain/LDAP1], etc. The label is simply a way to identify the LDAP server, which later you will see that the domain name will define the log name; e.g. below the log would be sssd_OID.log.
[domain/AD] -
Parameter | Value | Description |
description | OID 11.1.1.9.0 | This section is only a label. |
debug_level | 2 | Bit mask that indicates which debug levels will be visible; 9 is the highest. |
enumerate | true | Determines if a domain can be enumerated; true, users and groups are enumerated. |
min_id | 1000 | UID and GID limits for the domain. |
id_provider | ldap | The identification provider used for the domain. |
auth_provider | ldap | The authentication provider used for the domain. |
ldap_schema | rfc2307bis | Specifies the Schema Type in use on the target LDAP server. |
cache_credentials | true | Determines if user credentials are also cached in the local LDB cache. |
ldap_search_base | dc=my,dc=initech,dc=com | The default base DN to use for performing LDAP user operations. |
ldap_uri | ldaps://my.initech.com:3131 | The default base DN to use for performing LDAP user operations. |
ldap_default_bind_dn | cn=sssd_admin,cn=Users, dc=my,dc=initech,dc=com | The default bind DN to use for performing LDAP operations. |
ldap_default_authtok_type | password | The type of the authentication token of the default bind DN. |
ldap_default_authtok | <your password> | The authentication token of the default bind DN. Only clear text passwords are currently supported. |
ldap_tls_cacertdir | /etc/openldap/cacerts | Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. |
ldap_tls_reqcert | allow | Specifies what checks to perform on server certificates in a TLS session, if any. |
ldap_user_object_class | orclPerson | The object class of a user entry in LDAP. |
ldap_user_name | uid | The LDAP attribute that corresponds to the user's login name. |
ldap_user_uid_number | uidNumber | The LDAP attribute that corresponds to the user's id. |
ldap_user_gid_number | gidNumber | The LDAP attribute that corresponds to the user's primary group id. |
ldap_user_home_directory | homeDirectory | The LDAP attribute that contains the name of the user's home directory. |
ldap_user_shell | loginShell | The LDAP attribute that contains the path to the user's default shell. |
ldap_group_name | cn | The LDAP attribute that corresponds to the group name. |
ldap_group_object_class | posixGroup | The object class of a group entry in LDAP. |
ldap_group_gid_number | gidNumber | The LDAP attribute that contains the names of the group's members. |
ldap_group_member | uniqueMember | The LDAP attribute that contains the names of the group's members. |
Example:
[domain/OID]
# OID LDAP General
description = OID 11.1.1.9.0
debug_level = 9
enumerate = true
min_id = 1000
#
# OID LDAP Providers
id_provider = ldap
auth_provider = ldap
# OID LDAP General
ldap_schema = rfc2307
cache_credentials = true
#
# OID LDAP Connection Settings
ldap_search_base = dc=my,dc=initech,dc=com
ldap_uri = ldaps://oid.initech.com:3131
ldap_default_bind_dn = cn=sssd_admin,cn=Users,dc=my,dc=initech,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = Oracle123
#
# OID LDAP Use below if you are using SSL/TLS
#ldap_id_use_start_tls = true
ldap_tls_cacertdir = /etc/openldap/certs
ldap_tls_reqcert = allow
#
# OID LDAP Objectclass Mappings
ldap_user_object_class = orclPerson
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell
ldap_group_name = cn
ldap_group_object_class = posixGroup
ldap_group_gid_number = gidNumber
ldap_group_member = uniqueMember
High availability is accomplished by making sure the LDAP connection from SSSD is redundant. Adding high availability can be done in a couple of ways:
1. Configure sssd.conf with multiple LDAP URIs
2. Use a load balancer for the LDAPS hosts
This section will explain the configuration for option #1 above, but if option #2 is desired the previous steps for the sssd.conf configurations can be kept since the virtual IP hostname of the load balancer can be used against multiple LDAP servers to provide the redundancy.
OPTION 1 – Using sssd.conf with multiple URIs
The following sssd.conf parameters will need to be adjusted from the previous section including adding backup URIs for each [domain/<NAME>] section as needed.
[domain/<NAME>] -
Parameter | Value | Description |
ldap_uri | ldaps://ldaphost1.com:636, ldaps://ldaphost2.com:636 | Comma delimited list of primary LDAP servers in order of preference that SSSD should try to connect. |
ldap_backup_uri | ldaps://ldaphost3.com:636, ldaps://ldaphost4.com:636 | Failover LDAP server is tried if there are no primary servers available, and once a backup is used, after 31 seconds it tries the primary servers again periodically. Once a primary is contacted again, the current backup is replaced. |
Example:
[domain/AD]
ldap_uri = ldaps://ldap1.acme.com:636, ldaps://ldap2.acme.com:636
ldap_backup_uri = ldaps://ldap3.acme.com:636, ldaps://ldap4.acme.com:636
OPTION 2 – Using a Load Balancer
If a load balancer is used for high availability the following are required:
✓ TLS certificate is required on the Load Balancer connection
✓ LDAP communication needs to use TCP
✓ Load balancer periodically checks the LDAP server health
How the above are accomplished or configured is out-of-the-scope of this article. That said, one point on the LDAP server health check, I would recommend the load balancer be configured to use a BIND to the LDAP server in order to determine if it is responding versus doing a simple TCP ping. The reason is that there can be issues with the LDAP server yet the physical host is still up. If this happens anything trying to use the LDAP connection will continue to think it is still working fine as the load balancer will never pull out any of the LDAP servers that are not working.
Each time any change is made to the sssd.conf the SSSD service needs to be restarted. A better approach is as follows which not only stops and starts SSSD, but also clears the cache. First stop SSSD, remove the LDB cache, and start SSSD. Run the following commands as root.
[root@host] service sssd stop
[root@host] sss_cache -E
[root@host] rm -f /var/lib/sss/db/*
[root@host] service sssd start
Testing the solution is pretty straightforward. The following gives some basic steps to validate a user can authenticate and see their groups. However, it is recommended to validate that high availability also works --- HA testing is out-of-scope for this article.
Before you can initially login with a user using SSSD, UNIX expects certain attributes to exist for a user account; gid number, uid number, login shell, and a home directory.
1. Create a user in the LDAP store you want to test, this should be done for both Active Directory and OID11g or any additional LDAP servers.
2. Be sure to add values for the following attributes; the attributes can differ between LDAP identity stores.
NOTE: If using Active Directory and the SSSD option of ldap_id_mapping is used, there is nothing needed to change for an Active Directory account.
AD (If not using ldap_id_mapping) | Other LDAP Servers |
gidNumber | gidNumber |
uidNumber | uidNumber |
loginShell | loginShell |
unixHomeDirectory | homeDirectory |
3. Open a terminal window.
4. Enter “ssh jsmith@linuxhost” where jsmith is your username and linuxhost is the host of the Linux server, then press enter.
5. Enter a password and press enter.
6. If SSSD is working properly, you should immediately login and SSSD will automatically create a home directory if it does not exist.
TIP: The home directory is only created once, so on logging into another server that is configured with SSSD it may complain that the home directory does not exist. It is recommended that all the Linux servers use a shared mount where the users home directories will be located. |
Another verification this solution should be able to do is to query a user or group from a command-line.
1. As “root” you can enter some of the following commands. You should get details of the user returned, otherwise you may get an error message like “id: jsmith: No such user”, and if that is the case see the troubleshooting section.
a. getent passwd jsmith
b. id jsmith
c. id –u jsmith
2. As a logged in “user” on the system, at a command line some of the following commands can be used to return information about the current logged in user.
a. id
b. groups
c. passwd (Let’s user change their password, but there is a known issue with OID and Active Directory 2012R2 that does not allow SSSD to use passwd; see Known Issues section.)
Hopefully you were successful in implementing SSSD following the steps in this article. This can be a tricky implementation and frustrating. If you ran into problems, no worries, I have one last article, Part 4 of 4 - SSSD Authentication: Known Problems and Troubleshooting. In Part 4 I will cover known issues and tips on how to troubleshoot setting up and configuring SSSD. If you were successful, it would not be a bad idea anyway to check out Part 4 for simply the knowledge of known issues I have come across in my own experience.
I started with Oracle in 2005 and been a member of the Oracle A-Team since 2012 though have worked in Identity and Access Management since 1999. My journey with security continues the cloud that heavily includes Oracle Infrastructure Cloud (OCI). I enjoy writing articles built on real life use cases to help in areas where a standard document may not provide. I am a strong believer in learning by example to which I try to incorporate as many helpful tips, excellent diagrams, and instructional steps as I can.
Previous Post
Next Post