X

Best Practices from Oracle Development's A‑Team

How to setup SSSD on OID12c or OUD12c in OCI

Tim Melander
A-Team Cloud Solution Architect

Introduction

Implementing SSSD (System Security Services Daemon) seems to be a popular topic. I wrote a 4 part series on SSSD that covers things such as the architecture, LDAP requirements, installation step-by-step guidelines, and troubleshooting tips along with a specific article on implementing SSSD with Active Directory using Kerberos — Using SSSD with Kerberos and Active Directory to Terminal into an OCI Linux Machine. However, it seems with each flavor of LDAP there are very unique requirements and SSD can be picky and in fact tricky to configure. If everything is not implemented correctly you could spend days troubleshooting issues and losing your hair. To hopefully save you from premature balding this article brings more specifics on how to implement SSSD with Oracle Internet Directory 12c (OID12c) or Oracle Unified Directory 12c (OUD12c). My hope is to save you time on implementing SSSD quickly. Though this article points out the implementation on Oracle Cloud Infrastructure (OCI), the same information can be used for on-premises.  

Summary of Tasks

The following is the summary fo tasks you will complete to successfully implement SSSD on OID12c or OUD12c; let's get started. 

1. Update OCI Security Rules and or Firewall Rules
2. UNIX Specific LDAP Schema for SSSD
3. LDAP Server Specific SSSD Configuration Parameters
4. Open LDAPS and DNS Ports and Protocols
5. DNS must resolve LDAP Server Hostname
6. Get LDAP SSL or TLS Certificates
7. Install and Configure SSSD
8. Testing SSH
 

1. Update OCI Security or Firewall Rules

There are certain ports and protocols that SSSD will need open between each Linux server running SSSD and the LDAP servers.  If using a load balancer to front end the LDAP server the port for the load balancer will apply instead. Using the table below be sure each port for your respective LDAP server and DNS are applied to a VCN (Virtual Cloud Network) security rule on the subnet used for the Linux host.

Table 1: Security Rule or Firewall Port and Protocol List Requirements
Stateless IP Protocol Source Port Destination Port Description
No TCP All 53 DNS
No TCP All 3131, 1636 default OID and OUD LDAPS

 

2. UNIX Specific LDAP Schema for SSSD

In UNIX users and groups are required to follow a posix standard.  That means users and groups will need some values in order to authenticate and have permissions to your home directory.  This has nothing to do with SSSD, but is important to SSSD.  A user without a uidNumber or gidNumber will not be able to authenticate to the Linux host. In order to meet these requirements the following are needed. 

user

  • uidNumber - A UID number assigned to each user that needs to be unique
  • gidNumber - A GID number that is assigned to each user which represents their primary group

group

  • gidNumber - A GID number is assigned to each group which needs to be unique 

Below is a diagram that illustrates the link between a user and their primary group in LDAP.  Normally these attributes come from adding a posixAccount object class to a user and the posixGroup to a group.  If you use a custom class be sure to map those in the section that lays out the table for the schema. 

Diagram 1: Attribute gidNumber relationship between user and group

The following table shows the mapping between SSSD parameters in the sssd.conf and the LDAP schema.  These are all defaults, and if your schema is custom use this table to map the appropriate SSSD parameters.  If the table does not make sense contact your LDAP administrator. 

Table 2:  LDAP Schema Requirements
sssd.conf parameter Schema Value Schema Type Object Type Description
ldap_user_object_class inetOrgPerson objectclass user Objectclass that defines people or users
ldap_user_name uid attribute user Attribute that holds user username
ldap_group_object_class posixAccount objectclass user Objectclass required for a user unix posix values
ldap_user_uid_number uidNumber attribute user Attribute that holds user unique posix number
ldap_user_gid_number gidNumber attribute user Attribute that holds user primary group id number
ldap_user_home_directory homeDirectory attribute user Attribute that holds user home directory path
ldap_user_shell loginShell attribute user Inherits from objectclass posixAccount 
ldap_group_object_class posixGroup objectclass group Required objectclass for group unix posix values
ldap_group_name cn attribute group Attribute that defines common name often the RDN
ldap_group_member uniqueMember attribute group Attribute that defines the DN of the user member
ldap_group_gid_number gidNumber attribute group Attribute that holds the unique group id number

 

3. LDAP Server Specific SSSD Configuration Parameters

For SSSD to work with standard LDAP servers like OID12c or OUD12c it requires some mapping of parameters that point to the actual LDAP server.  The following is a table that will be the most basic parameters to get SSSD to work, but there are many more parameters you can use listed in the sssd-ldap(5) - Linux man page.

Table 3: SSSD Basic LDAP Required Variables
Variable Example Configuration File Description
<ldap_hostname> oid.acme.com ldap.conf & sssd.conf The FQDN of OID or load balancer VIP
<ldaps_port> 3131 or 1636 ldap.conf & sssd.conf The default LDAPS port for OID or OUD
<ldap_basedn> dc=oracle,dc=com ldap.conf & sssd.conf The top base DN of the directory server
<ldap_user_basedn> cn=Users,dc=oracle,dc=com sssd.conf The user base DN for all users
<ldap_group_basedn> cn=Groups,dc=oracle,dc=com sssd.conf The group base DN for all groups
<ldap_bind_account> uid=readonlyuser,cn=users,
dc=oracle,dc=com   **
sssd.conf Bind account that verifies passwords and runs ldapsearches
<ldap_bind_password> ********** sssd.conf Bind account password, recommend a complex password

** Recommend creating a service BIND account with limited READ-ONLY access privileges.

 

4. Open LDAPS and DNS Ports and Protocols

In order for SSSD to properly communicate with the LDAP server some firewall and SELinux rules need to be configured on the host running the LDAP server.

1.  On the host running OID or OUD open up a non-standard LDAPS port if your LDAPS port is not 636.

sudo firewall-cmd --permanent --add-port=<ldaps_port>/tcp
sudo firewall-cmd --reload
2. Allow SELinux to use a non-standard LDAPS port if your LDAPS port is not 636.
 
sudo semanage port -a -t ldap_port_t -p tcp <ldaps_port>

 

5. DNS must resolve LDAP Server Hostname

For SSSD to work properly it must be able to communicate from the host it is running on to the LDAP server.  You can determine this by running either nslookup or dig on the SSSD host.

nslookup <ldap_hostname>

dig SRV _ldap._tcp.<ldap_hostname>

 

6. Get LDAP SSL or TLS Certificates

In order for ssh authentication using SSSD to work with standard LDAP servers LDAP communication is required to be over SSL or TLS. The following sections provide some simple steps on generating SSL certificates.

How To Generate OID12c Self-Signed Certificate

The following steps help simplify how to generate a self-signed certificate for OID12c based on the My Oracle Support (MOS) document "Using MOS OID 12c: How to Create a CA Signed (OR Self-Signed) Auto-Login Wallet Using orapki and Configure a New OID Component for SSL Server Authentication (Mode 2) (Doc ID 2319432.1)”. If using a real CA or your own CA the steps are similar except for importing the CA certificate, which is explained with more detail in MOS Doc ID 2319432.1. I should note my instructions are based on a OID12c standalone deployment. If you have deployed OID12c with WebLogic it may be a good idea to follow the MOS Doc ID 2319432.1.

1. Terminal into the OID12c host and set some environment variables.

export ORACLE_HOME=<path_to_oid_oracle_home>/bin
export DOMAIN_HOME=<path_to_domain_home>
export PATH=$ORACLE_HOME:$PATH
2. From a terminal on the OID12c server create a self-signed certificate using the FQDN OID hostname as follows. NOTE: Make sure to modify the variable below.
cd $DOMAIN_HOME/system_components/OID/oid1/security
orapki wallet create -wallet ./ -auto_login_only
orapki wallet remove -trusted_cert_all -wallet ./ -auto_login_only
orapki wallet add -wallet ./ -self_signed -dn "cn=<oid_fqdn_hostname>" -keysize 2048 -sign_alg sha256 -validity 3650 -auto_login_only
orapki wallet display -wallet ./
3. Update OID12c server attributes with the following values using ldapmodify with the following LDIF.
IMPORTANT: Modify the orclsslwalleturl path to your wallet that was created in the previous step.
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsslauthentication
orclsslauthentication: 32

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclcryptoversion
orclcryptoversion: 24

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsslinteropmode
orclsslinteropmode: 0

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsslwalleturl
orclsslwalleturl: file:/opt/oracle/product/oid12.2.1.4.0/user_projects/domains/oid_domain/security
4. From the terminal restart OID server using the following commands.
$DOMAIN_HOME/bin/stopComponent.sh oid1
$DOMAIN_HOME/bin/startComponent.sh oid1
5. Now from the SSSD host open the ldap.conf
sudo vi /etc/openldap/ldap.conf
6. Modify the ldap.conf with your own values and save it.
BASE            <oid_ldap_base>
URI             ldaps://<oid_ldap_hostname>:<oid_ldaps_port>
TLS_CACERTDIR   /etc/openldap/certs
TLS_REQCERT     allow

7. Grab the SSL certificate and create a PEM file; be sure to first modify the hostname and port variables below. 
openssl s_client -connect <oid_hostname>:<oid_ldaps_port> -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > sudo tee /etc/openldap/certs/<oid_hostname>.pem
8. Create the proper hash link to the OID SSL certificate.
sudo cacertdir_rehash /etc/openldap/certs

 

How To Generate OUD12c Self-Signed Certificate 

Please follow the instructions on the official Oracle docs Administrating Oracle Unified Directory release 12.2.1.3 in section 26 Configuring Security Between Clients and Servers. This covers both self-signed and personal or public CAs. Regardless of which you decide the last few steps like for the SSL OID12c certificates are the same.  The steps are added below for your convenience. 

1. Follow the official Oracle docs Administrating Oracle Unified Directory release 12.2.1.3 in section 26 Configuring Security Between Clients and Servers.

2. Terminal to SSSD host open and the ldap.conf
sudo vi /etc/openldap/ldap.conf
3. Modify the ldap.conf with your own values and save it.
BASE            <oud_ldap_base>
URI             ldaps://<oud_ldap_hostname>:<oud_ldaps_port>
TLS_CACERTDIR   /etc/openldap/certs
TLS_REQCERT     allow

4. Grab the SSL certificate and create a PEM file; be sure to first modify the hostname and port variables below. 
openssl s_client -connect <oud_hostname>:<oud_ldaps_port> -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > sudo tee /etc/openldap/certs/<oud_hostname>.pem
5. Create the proper hash link to the OUD SSL certificate.
sudo cacertdir_rehash /etc/openldap/certs

 

7. Install and Configure SSSD

This section installs SSSD and configures all the necessary components to ssh into the Linux host.

1. Enable the proper ol7 repo

sudo yum install -y oracle-release-el7
sudo yum-config-manager --quiet --enable ol7_latest --enable ol7_optional_latest --enable ol7_addons
2. Install the SSSD package
sudo yum install -y sssd sssd-tools
3. Create sssd.conf configuration file
sudo vi /etc/sssd/sssd.conf
4. Paste the following configuration into the sssd.conf and be sure to modify the variables and any other parameters needed, and then save it. A special note on parameter "sudo_provider = none” related to OID12c; see section troubleshooting.
[sssd]
#debug_level = 9
domains = OID
config_file_version = 2
reconnection_retries = 3
services = nss, pam

[nss]
#debug_level = 9
reconnection_retries = 3
# global default user parameters
default_shell = /bin/bash
fallback_homedir = /home/%u

[pam]
#debug_level = 9
reconnection_retries = 3

[domain/OID]
#debug_level = 9
# ldap connection parameters
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = none
ldap_uri = ldaps://<ldap_hostname>:<ldaps_port>
#ldap_backup_uri = ldaps://<ldap_hostname>:<ldaps_port>
ldap_search_base = 
ldap_default_bind_dn = <ldap_bind_account>
ldap_default_authtok_type =
ldap_default_authtok = 
ldap_schema = rfc2307bis
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/certs
enumerate = true
cache_credentials = true
use_fully_qualified_names = false

# ldap user parameters
ldap_user_search_base = <ldap_user_basedn>
ldap_user_object_class = inetOrgPerson
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell
ldap_user_member_of = uniquemember

# ldap group parameters
ldap_group_search_base = <ldap_group_basedn>
ldap_group_object_class = posixGroup
ldap_group_name = cn
ldap_group_gid_number = gidNumber
ldap_group_member = uniqueMember
5. Change the permissions for the sssd.conf to 600.
sudo chmod 600 /etc/sssd/sssd.conf
6. Using authconfig run the configuration for SSSD.
sudo authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

7. The example sssd.conf has a couple parameters for the BIND account password and type, but the values are blank.  We need to finish things up and use the SSSD tool sss_obfusccute to obfuscate the LDAP password.  This will modify sssd.conf  to change the parameter ldap_default_authtok_type value from "password" to "obfuscated_password" and the parameter ldap_default_authtok value from clear text if present to an obfuscated password. The domain "<sssd_domain>" is a variable you will replace with your real domain defined in sssd.conf under the [sssd] section; e.g. "domains = OUD".  When running this command you will be prompted for the BIND password twice.  Restart sssd after completing this to make sure all changes are loaded. After completing this you can review the sssd.conf and see the changes.

sudo sss_obfuscate -d <sssd_domain>
Enter password:  **********
Re-enter password: **********

sudo systemctl restart sssd

8. Make sure SSSD starts on reboot

sudo systemctl enable sssd
9. Allow password authentication by changing the PasswordAuthentication parameter to “yes" and save.
sudo vi /etc/ssh/sshd_config

PasswordAuthentication yes        <-- change from no to yes

sudo systemctl restart sshd

8. Testing SSH

Testing is pretty simple, run ssh command to login and enter the credentials that are stored in OID12c. If it fails turn on all the debugging to 9 in all the sections of /etc/sssd/sssd.conf and monitor mostly the sssd_OID.log under /var/log/sssd/ path.

ssh username@linux_host

 

Known Issue

When SSSD starts it does several initial startup things.  One item is a LDAP search for a sudo schema as follows.

(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(&(!(sudoHost=*))(cn=defaults))(sudoHost=ALL)(sudoHost=sssd)(sudoHost=sssd.sub06021701110.sharedvcn.oraclevcn.com)(sudoHost=10.0.0.58)(sudoHost=10.0.0.0/24)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=oracle,dc=com].

OID12c and even OID11g return a protocol error that causes SSSD to mark the OID server offline if there is only a single OID server configured; see the following log error. This problem is not present when using OUD or Active Directory. Coincidently this error also causes problems if you want to use the chpass_provider parameter in sssd.conf to allow password change policies to be implemented. 

(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [sdap_get_generic_op_finished] (0x0400): Search result: Protocol error(2), Bad Search Filter
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [sdap_get_generic_op_finished] (0x0040): Unexpected result from ldap: Protocol error(2), Bad Search Filter
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [sdap_op_destructor] (0x2000): Operation 4 finished

 

When this happens SSSD next checks for the related data in cache and of course cannot find anything since it just started the service, then tries a failover LDAP server and if not configured it puts the only LDAP server in an offline state. Even if you try to ssh to login SSSD never sends the bind to the LDAP server to evaluate credentials though if you run “id ” it returns the user. You can easily identify this problem by turning on the debug_level = 9 in the [sssd] section along with the [domain/OID] section in the sssd.conf and finally restart SSSD. After starting SSSD you can run a grep command “grep fail /var/log/sssd/sssd_OID.log” and something similar to the following will be returned. Notice the Server resolution failed errors.

(Wed Jul 8 13:38:39 2020) [sssd[be[OID]]] [fo_context_init] (0x0400): Created new fail over context, retry timeout is 30
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [5]: Input/output error
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [be_ptask_done] (0x0040): Task [SUDO Full Refresh]: failed with [11]: Resource temporarily unavailable
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(Wed Jul 8 13:38:40 2020) [sssd[be[OID]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(Wed Jul 8 13:39:44 2020) [sssd[be[OID]]] [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [5]: Input/output error
(Wed Jul 8 13:39:44 2020) [sssd[be[OID]]] [be_ptask_done] (0x0040): Task [SUDO Full Refresh]: failed with [11]: Resource temporarily unavailable
(Wed Jul 8 13:39:44 2020) [sssd[be[OID]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error

 

There are other ways to use LDAP groups to grant sudo rights. So the fix is to add the following parameter to /etc/sssd/sssd.conf within the [domain/OID] section. The restart sssd and this should disable it from searching the sudorers schema.

[domain/OID]
sudo_provider = none

 

Summary

Implementing SSSD can be pretty simple as long as all of the above tasks have been followed properly.  If not, I have worked with customers that spent weeks getting it to work including me and it can certainly be frustrating.  Debugging can be very tricky for sure.  Hence the reason I created this article to focus on Oracle Internet Directory and Oracle Unified Directory because there has been an uptick in demand on getting this working in Oracle Cloud Infrastructure.  In summary I hope this article spares you a lot of wasted time to get SSSD quickly up and running.  Enjoy! 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha