Configuring SUDO with OpenLDAP

21/08/2025

0 Views 0

SaveSavedRemoved 0

A Step-by-Step Guide to Centralized Sudo Management with OpenLDAP

Managing user permissions across a growing infrastructure is one of the most critical challenges for any system administrator. Editing the /etc/sudoers file on individual servers is not only tedious but also prone to error and security risks. A single misconfiguration can lead to privilege escalation vulnerabilities or lockouts. Fortunately, there is a robust, scalable solution: centralizing your sudo rules within an OpenLDAP directory.

By integrating sudo with OpenLDAP, you create a single source of truth for user privileges. This approach dramatically simplifies administration, enhances security, and ensures consistent policy enforcement across all your Linux systems.

This guide will walk you through the process of configuring your OpenLDAP server and Linux clients to manage sudo permissions centrally.

Why Centralize Sudo Rules with OpenLDAP?

Before diving into the technical steps, it’s important to understand the benefits of this configuration:

Centralized Control: Manage all sudo rules from one location. Adding, removing, or modifying a user’s privileges is done once in the LDAP directory and automatically propagates to all connected servers.
Enhanced Security: Eliminate configuration drift between servers. You can enforce a strict, consistent security policy and easily audit who has access to what.
Scalability: As you add more servers to your environment, they can immediately inherit the centralized sudo policies without any manual configuration on the new machines.
Simplified Auditing: Quickly and easily review all sudo permissions by querying the LDAP directory, rather than logging into dozens of machines to inspect local files.

Prerequisites

To follow this guide, you will need:

A functioning OpenLDAP server.
Root or equivalent sudo access on the OpenLDAP server and the client machines.
Basic knowledge of LDAP concepts like Distinguished Names (DNs), schemas, and LDIF files.

Step 1: Extending the OpenLDAP Schema for Sudo

By default, OpenLDAP doesn’t know what a “sudo rule” is. The first step is to extend its schema to understand the objects and attributes required for sudo.

The sudo project provides the necessary schema file. You’ll need to add it to your OpenLDAP configuration.

Locate the Sudo Schema: The schema file, typically named sudo.schema, is often included with the sudo package. You can find it in directories like /usr/share/doc/sudo-ldap/ or /usr/share/doc/sudo/.
Convert and Add the Schema: Modern OpenLDAP configurations manage schemas as LDIF files within the cn=config directory. First, you must create a dedicated LDIF file for the schema. Create a file named sudo_schema.ldif and add the following content, ensuring you convert the sudo.schema file contents into this format.
A simplified conversion might involve creating an LDIF file that loads the schema definition. However, the best practice is to load it into the cn=config database. A common method is to place the sudo.schema file in your OpenLDAP schema directory and add a directive in your slapd.conf or, for cn=config, create an LDIF file to load it.
For example, create convert_schema.conf:
```
include /path/to/your/sudo.schema
```
Then convert it:
```
slapcat -f convert_schema.conf -F /tmp/ldif.d -n 0
```
This will generate an LDIF file in /tmp/ldif.d which you can then add to your directory using ldapadd.
Restart OpenLDAP: After adding the schema, restart your OpenLDAP service to apply the changes.

Step 2: Creating Sudo Roles in the LDAP Directory

With the schema in place, you can now create entries to define your sudo rules. These rules are stored as sudoRole objects. It’s good practice to create a dedicated Organizational Unit (OU) for them, such as ou=Sudoers.

Here is an example LDIF file (new_role.ldif) that creates a rule for a group of system administrators:

dn: cn=sysadmins,ou=Sudoers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: sysadmins
description: Sudo role for the System Administration team
sudoUser: %sysadmins
sudoHost: ALL
sudoCommand: ALL
sudoOption: !authenticate

Let’s break down the key attributes:

dn: The Distinguished Name uniquely identifies this rule in the directory.
objectClass: sudoRole: This is the critical object class that defines the entry as a sudo rule.
cn: The common name for the rule (e.g., “sysadmins”).
sudoUser: Specifies which user or group this rule applies to. Using a % prefix indicates a group name, which is highly recommended for easier management.
sudoHost: Defines which hosts the rule applies to. ALL is a common value.
sudoCommand: The command(s) the user is allowed to run. ALL grants full privileges. For better security, you should be as specific as possible (e.g., /usr/sbin/reboot).
sudoOption: Allows you to specify options like !authenticate, which means the user won’t be prompted for their password when using sudo. Use this option with extreme caution.

Use the ldapadd command to import this LDIF file into your directory:

ldapadd -x -W -D "cn=admin,dc=example,dc=com" -f new_role.ldif

Step 3: Configuring Linux Clients to Use LDAP for Sudo

The next step is to configure your Linux clients to look up sudo rules in OpenLDAP. The modern and recommended method is to use the System Security Services Daemon (SSSD). SSSD acts as a broker, caching credentials and rules, which improves performance and allows for offline authentication.

Install Necessary Packages:

sudo yum install sssd sssd-tools sudo-ldap -y  # For RHEL/CentOS
sudo apt-get install sssd sssd-tools ldap-utils -y # For Debian/Ubuntu

Configure SSSD:
Edit the SSSD configuration file at /etc/sssd/sssd.conf. You need to add sudo to the list of services and create a [sudo] domain section.

[sssd]
services = nss, pam, sudo
config_file_version = 2
domains = default

[nss]
# ... your nss settings ...

[pam]
# ... your pam settings ...

[domain/default]
# ... your existing domain settings for authentication ...
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
id_provider = ldap
auth_provider = ldap
# ... other settings ...

# Add this new section for Sudo
[sudo]
ldap_sudo_search_base = ou=Sudoers,dc=example,dc=com

The key addition here is services = ..., sudo and the [sudo] section pointing to the OU where you stored your sudoRole objects.

Set Permissions and Restart SSSD:
The sssd.conf file contains sensitive information, so ensure its permissions are correct.
bash sudo chmod 600 /etc/sssd/sssd.conf sudo systemctl restart sssd sudo systemctl enable sssd

Step 4: Update the Name Service Switch (NSS)

Finally, you must tell the operating system to use SSSD for sudo lookups. This is done by editing the /etc/nsswitch.conf file.

Find the sudoers line and modify it to include sss:

# Original line might be:
# sudoers: files

# Modified line:
sudoers: files sss

This configuration tells the system to first check the local /etc/sudoers file and, if no match is found, to then query SSSD (which in turn queries OpenLDAP).

Step 5: Verification and Troubleshooting

To verify that the configuration is working, log in as a user who is part of a group defined in an LDAP sudo rule (like the sysadmins group in our example).

Run the sudo -l command. This will list the sudo permissions for the current user. If everything is configured correctly, you should see the rules fetched from OpenLDAP.

$ sudo -l
Matching Defaults entries for user_test on this host:
    ...

User user_test may run the following commands on this host:
    (ALL) ALL

If you encounter issues, the first place to look is the SSSD sudo log file at /var/log/sssd/sssd_sudo.log. It provides detailed information about LDAP queries and any errors encountered. You can also use ldapsearch from the client to ensure it can reach the OpenLDAP server and see the sudoRole objects.

By centralizing sudo management with OpenLDAP, you build a more secure, maintainable, and scalable infrastructure, freeing you from the risk and repetition of managing local configuration files.

Source: https://kifarunix.com/how-to-configure-sudo-via-openldap-server/