Copyright (c) 2024, Oracle. All rights reserved. Oracle Confidential.

LDAP configuration example in Exadata compute nodes and storage servers using SSSD (Doc ID
3020122.1)

In this Document

Purpose
Scope
Details
Document notation
Hostnames
Environment connection scenario
LDAP – NFS example data
Configuring system services
Customizing SSSD
Customizing NSCD
Verifying LDAP user accounts
Customizing Autofs
Using LDAP user account
SSSD software updates in Exadata
Debugging and troubleshooting documentation
References

APPLIES TO:

Oracle Exadata Storage Server Software - Version 23.1.2.0.0 and later

Linux x86-64

PURPOSE

Beginning with Oracle Exadata Storage Server Software version 23.1.2.0.0, full support is introduced for System Security
Services Daemon (SSSD) – Lightweight Directory Access Protocol (LDAP) configuration and usage across all server
environments (storage servers, database bare metal, Dom0/DomU, KVM Host/Guest). Exadata database nodes and storage
servers can use SSSD to access authentication providers (i.e. external LDAP server) so remote data can be cached in local
storage. These features are supported at the operating system level.

The purpose of this note is to exemplify an environment in which these technologies function together with a common
objective. In this case, the protocols / services are configured to enable a single-sign on (SSO) strategy for operating system
user accounts in Exadata systems.

NOTE: It is strongly recommended to test any configuration before applying it in a production environment.

SCOPE

NOTE: It is strongly recommended to read "How to configure Kerberos and SSSD-KCM in Exadata compute nodes and
cells (Doc ID 2948255.1)" before implementing any concept explained in this document.
 Kerberos best practices and configurations are not covered in this document, but are needed if an Exadata server provides
a Kerberos-aware service..

All the content in this note is intended for system administrators, who are allowed to modify configuration files, customize
system units (i.e. services and sockets), and manage operating system user accounts.

For the configurations covered in this document to function properly, the following technical requirements must be met:

An external LDAP server must have been configured to store user data (identities) in a logical and organized manner, so
it can be automatically retrieved by remote clients using SSSD.
An external NFS server must have been configured to share the home directories of the users (managed by the external
LDAP server) to the remote clients.

In this scenario, the LDAP and NFS services are running in their standard network port.

NOTE: For simplification purposes, in this case, the LDAP and NFS services are provided by the same sever.

DETAILS

Document notation
Hostnames
external-ldap-server (LDAP and NFS server)
exadb01 (Exadata database node). This Exadata node uses SSSD to communicate and access the external LDAP
server. Additionally, the node provides SSH as a Kerberos-aware service (configured to accept Kerberos tickets as
authentication mechanism for user account access).
PC-01: Corporate PC, configured as Kerberos client.

Environment connection scenario

exadb01 requests the ldapuser1 user identity from external-ldap-server and caches the data in local storage using
SSSD.
From PC-01, a Kerberos ticket is requested for ldapuser1. Once the ticket is granted, it is used to authenticate to the
Kerberos-aware service (SSH) provided by exadb01.
If the ticket provided by PC-01 is valid, exadb01 uses Autofs to automatically mount the NFS - managed home
directory of ldapuser1. Once the home directory is mounted, an SSH session is forwarded to PC-01.
LDAP – NFS example data
Let us consider the following data in the LDAP server database, which defines the ldapuser1 user account. The entries are
represented in LDAP Data Interchange Format (LDIF).

Top class

dn: dc=example-ldap-domain,dc=com
dc: example-ldap-domain
objectClass: top
objectClass: domain
structuralObjectClass: domain
creatorsName: cn=Manager,dc= example-ldap-domain,dc=com

Users organizational unit

dn: ou=User,dc=example-ldap-domain,dc=com
ou: User
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
creatorsName: cn=Manager,dc=example-ldap-domain,dc=com

Groups organizational unit

dn: ou=Group,dc=example-ldap-domain,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
creatorsName: cn=Manager,dc=example-ldap-domain,dc=com
User account entry

dn: uid=ldapuser1,ou=User,dc=example-ldap-domain,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
cn: ldapuser1
sn: user1
uid: ldapuser1
uidNumber: 24872
gidNumber: 24872
homeDirectory: /scratch/ldapuser1
loginShell: /bin/bash
structuralObjectClass: inetOrgPerson
creatorsName: cn=Manager,dc=example-ldap-domain,dc=com
userPassword:: wergwgknwergnwe23lkbkljljhblblkj5l34lkjnnlQThHVm4=

Let us consider the following NFS share. In this configuration scenario, the home directory of ldapuser1 is created under
/scratch, which is shared by the NFS server.

[root@external-ldap-server ~]# showmount -e

Export list for external-ldap-server:

/scratch *

NOTE: If the home directory of the LDAP-managed user is not shared via NFS, applications will fail to mount the home
directory and clients will not be able to use the user’s files.

Configuring system services

Customizing SSSD
At a high level, SSSD provides a set of daemons to manage access to authentication mechanisms. When properly configured,
SSSD acts as an intermediary between local users and remote authentication providers (i.e. LDAP), reducing the workload of
both the remote servers and the local system. Its caching capabilities make offline authentication possible. Once retrieved
from the remote identity providers, user data can be locally cached in the system. In this case, even if the identity provider is
not available, the cached credentials can be used to authenticate to online network services in the server domain.

In this case, the SSSD configuration file (/etc/sssd/sssd.conf) will stipulate the following:

LDAP server network information (i.e. FQDN or URI).

Credentials to access LDAP the server data.
General query options.
LDAP data to request.
How the LDAP data will be managed in local system.

NOTE: For the SSSD service to properly start, the /etc/sssd/sssd.conf configuration file must be owned by root and
must have restricted access permissions (recommended is 600).

Let us consider the following configuration.

[sssd]
domains = example-sssd-domain.com
services = pam, nss
config_file_version = 2

[nss]
filter_groups = root
filter_users = root

[domain/example-sssd-domain.com]
id_provider = ldap
ldap_uri = ldap://external-ldap-server.com
cache_credentials = True
ldap_search_base = dc=example-ldap-domain,dc=com
ldap_default_bind_dn = cn=Manager,example-ldap-domain,dc=com
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = <LDAP manager authentication token>
ldap_access_filter = (objectClass=posixAccount)
ldap_user_search_base = ou=User,dc=example-ldap-domain,dc=com
ldap_user_object_class = posixAccount
ldap_user_name = uid
ldap_group_search_base = ou=Group,dc=example-ldap-domain,dc=com
ldap_group_object_class = posixGroup
ldap_group_name = cn
ldap_id_use_start_tls = True
ldap_tls_reqcert = allow
ldap_tls_cacert = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
ldap_access_filter = (objectClass=posixAccount)
ldap_user_uuid = entryUUID
ldap_user_shell = loginShell
ldap_user_home_directory = homeDirectory
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
ldap_group_uuid = entryUUID
ldap_group_member = memberUid
use_fully_qualified_names = False
enumerate=True
debug_level=6

NOTE: If a firewall (i.e. iptables or nftables) is configured in the Exadata database node or storage server, proper access
rules may be needed to allow incoming traffic from the external LDAP server.

For systems with an "iptables" firewall, use the following commands.

[root@exadb01 ~]# iptables -I INPUT -i eth0 -p tcp -s <LDAP server IP address>/32 -j ACCEPT
[root@exadb01 ~]# iptables -I INPUT -p tcp -m tcp -s <LDAP server IP address>/32 -j ACCEPT

In this case, two new "ACCEPT" rules are inserted in the iptables configuration.

The first rule allows incoming traffic from the external LDAP server via eth0 network interface.
The second rule is generic. It allows incoming traffic from the external LDAP server on any network interface.

NOTE: Configuring TLS certificate trust and validation between the external LDAP server and the Exadata nodes increases
the communication security. It is recommended to validate any TLS configuration in a non-production environment.
 Once the configuration is complete, the SSSD service must be enabled and started. The service will request the LDAP users'
data and the local cache will be populated with the retrieved data.

[root@exadb01 ~]# systemctl enable --now sssd.service

NOTE: If the LDAP server is not running properly, SSSD will fail to collect the data. SSSD functionality and performance
can be debugged using the log files present in /var/log/sssd.

Customizing NSCD
NSCD (Name Service Cache Daemon) is a service shipped in the Exadata image, which provides caching operations for the
most common name service requests. The NSCD configuration, present in Exadata, is likely to conflict with SSSD caching.

For both services to run without interference, the NSCD configuration must be modified.

Edit the NSCD configuration file (/etc/nscd.conf) and set the “enable-cache” directives to the following values.

enable-cache passwd no
enable-cache group no
enable-cache hosts yes
enable-cache services no
enable-cache netgroup no

NOTE: Preserve the rest of the configuration present in /etc/nscd.conf.

Once the custom configuration is applied, the NSCD system service must be restarted.

[root@exadb01 ~]# systemctl restart nscd.service

Verifying LDAP user accounts

Once the services are properly configured, system logs and local cache can be analyzed to prove if the LDAP user accounts
were properly requested and stored in local storage.

Check the binary cache file of the SSSD domain configured.

[root@exadb01 ~]# grep -i ldapuser1 /var/lib/sss/db/cache_example-sssd-domain.com.ldb

Binary file /var/lib/sss/db/cache_example-sssd-domain.com.ldb matches

Check the SSSD log of the domain configured.

[root@exadb01 ~]# grep -i ldapuser1 /var/log/sssd/sssd_example-sssd-domain.com.log

...
(2024-01-23 5:12:58): [be[example-sssd-domain.com]] [sysdb_store_user] (0x0400): User
"[email protected]" has been stored
(2024-01-23 5:12:58): [be[example-sssd-domain.com]] [sdap_save_group] (0x0400): Processing group
[email protected]
(2024-01-23 5:12:58): [be[example-sssd-domain.com]] [sdap_save_group] (0x0400): Storing info for
group [email protected]
(2024-01-23 5:12:58): [be[example-sssd-domain.com]] [sysdb_set_entry_attr] (0x0200): Entry
[name=ldapuser1@example-ldap-domain,cn=groups,cn=example-ldap-domain,cn=sysdb] has set [cache,
 ts_cache] attrs.
(2024-01-23 5:12:58): [be[example-sssd-domain.com]] [sysdb_store_group] (0x0400): Group
"[email protected]" has been stored
(2024-01-23 5:25:49): [be[example-sssd-domain.com]] [sdap_get_generic_ext_step] (0x0400): [RID#54]
calling ldap_search_ext with [(&(memberUid=ldapuser1)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!
(gidNumber=0))))][ou=Group,dc=example-ldap-domain,dc=com].

It can be noticed how ldapuser1 is recognized as a valid user, even though it was not locally created in exadb01 and its
identity data is not present in the user identity local files.

[root@exadb01 ~]# grep -i ldapuser1 /etc/passwd

[root@exadb01 ~]# grep -i ldapuser1 /etc/group
[root@exadb01 ~]# grep -i ldapuser1 /etc/shadow
[root@exadb01 ~]# id ldapuser1
uid=24872(ldapuser1) gid=24872(ldapuser1) groups=24872(ldapuser1)

Customizing Autofs
Autofs is a system daemon that manages mount points as needed by system applications. At a high level, this service
automatically mounts a file-system when an internal application or user request it. Additionally, once the mount point managed
by the service becomes inactive or unused, it is automatically dismounted.

In this case Autofs can be configured to, after successful client authentication, mount home directories (belonging to the
LDAP-managed user accounts) upon session requests from the SSH server.

In the Autofs main mapping file (/etc/auto.master) add the following line.

<Directory shared by the NFS server> /etc/auto.home --timeout=30

The previous line defines that any configuration related to the directory shared by the NFS server is managed in a separate file
(/etc/auto.home).

In /etc/auto.home add the following.

* <external-ldap-server IP address>:<Directory shared by the NFS server>/&

Once the custom configuration is applied, the Autofs system service must be enabled and started.

[root@exadb01 ~]# systemctl enable --now autofs.service

NOTE: If a firewall (i.e. iptables or nftables) is configured in the Exadata database node or storage server, proper access
rules may be needed to allow incoming traffic from the NFS server.

For systems with an "iptables" firewall, use the following commands.

[root@exadb01 ~]# iptables -I INPUT -i eth0 -p tcp -s <NFS server IP address>/32 -j ACCEPT
[root@exadb01 ~]# iptables -I INPUT -p tcp -m tcp -s <NFSserver IP address>/32 -j ACCEPT

In this case, two new "ACCEPT" rules are inserted in the iptables configuration.

The first rule allows incoming traffic from the NFS server via eth0 network interface.
 The second rule is generic. It allows incoming traffic from the NFS server on any network interface.

Using LDAP user account

In this scenario, PC-01 only requires Kerberos client configuration to be able to use the LDAP user account cached in
exadb01.

First, request the Kerberos ticket of the LDAP user from the external KDC.

[ldapuser1@PC-01 ~]# kinit -V

Using default cache: 24872
Using principal: [email protected]
Password for [email protected]:
Authenticated to Kerberos v5

Verify the Kerberos ticket was granted and successfully cached in the system.

[ldapuser1@PC-01 ~]# klist

Ticket cache: KCM:24872
Default principal: [email protected]
Valid starting Expires Service principal
01/23/24 07:31:55 01/24/24 07:31:55 krbtgt/[email protected]
renew until 01/24/24 03:31:55

Use the Kerberos ticket of the LDAP user to access exadb01 via SSH.

[ldapuser1@PC-01~]# ssh -K ldapuser1@exadb01

Last login: Mon Jan 22 03:39:33 2024 from PC-01.example.com

Verify the SSH session was successfully stablished in exadb01. Retrieve the current session server's data.

[ldapuser1@exadb01 ~]$ hostnamectl

Static hostname: exadb01.example.com
Icon name: computer-vm
Chassis: vm
Machine ID: <Machine ID>
Boot ID: <Boot ID>
Virtualization: kvm
Operating System: Oracle Linux Server 8.8
CPE OS Name: cpe:/o:oracle:linux:8:8:server
Kernel: Linux 5.4.17-2136.322.6.3.el8uek.x86_64
Architecture: x86-64

Verify the home directory of the LDAP user was successfully mounted.

[ldapuser1@exadb01 ~]$ df -h | grep -i ldapuser1

<NFS Server IP address>:/scratch/ldapuser1 250G 73G 178G 29% /scratch/ldapuser1

SSSD software updates in Exadata

Upon Exadata image upgrades, all the SSSD operating system packages will be updated and their dependencies will be
automatically resolved. Changes to SSSD configuration files will be preserved.

Debugging and troubleshooting documentation

Further details of SSSD configuration and usage in Oracle Linux 8 may be found in the following documentation.

Oracle Linux 8 - Setting Up System Users and Authentication - Section 3 "Using the System Security Services Daemon"

LDAP and NFS functionality and support may vary between different service providers.

REFERENCES

NOTE:2948255.1 - How to configure Kerberos and SSSD-KCM in Exadata compute nodes and cells
Didn't find what you are looking for?