SSSD-SUDO(5)
β¨ SSSD-SUDO β¨
okay bestie, welcome to the sssd-sudo glow-up π
β this is from the File Formats and Conventions corner of the manual world, section 5, and it's literally all about making sudo and SSSD be besties.
π NAME π
sssd-sudo β configuring sudo with the SSSD back end π«Ά
πΈ DESCRIPTION πΈ
So this page is the whole tutorial on how to set up sudo(8) so it vibes with sssd(8), plus the tea on how SSSD caches your sudo rules. No cap, that's the entire plot.
π CONFIGURING SUDO TO COOPERATE WITH SSSD π
If you want SSSD to be a source of sudo rules (and you do, trust), you gotta add sss to the sudoers entry inside nsswitch.conf(5). That's it. That's the move. β¨
Say you want sudo to look in the standard sudoers(5) file first β which should be holding the rules for your local users β and then hit up SSSD? Then your nsswitch.conf file should have this exact line:
sudoers: files sss
More deets about setting the sudoers search order from nsswitch.conf, plus all about the LDAP schema used to store sudo rules in the directory? That's in sudoers.ldap(5). Go look, iykyk. π¦
Note: if you wanna use netgroups or IPA hostgroups in your sudo rules, you also need to correctly set nisdomainname(1) to your NIS domain name (which equals your IPA domain name when you're using hostgroups). Don't skip this, bestie, it matters. π
π CONFIGURING SSSD TO FETCH SUDO RULES π
Everything you need to do on the SSSD side is extend your list of services with "sudo" in the [sssd] section of sssd.conf(5). And if you wanna speed up those LDAP lookups? You can also set a search base for sudo rules using the ldap_sudo_search_base option. Zoom zoom. π¨
Here's an example showing how to configure SSSD to download sudo rules from an LDAP server:
[sssd]
services = nss, pam, sudo
domains = EXAMPLE
[domain/EXAMPLE]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
Now, important thing to note π: on platforms where systemd is supported, there's no need to add the "sudo" provider to the list of services, because it became optional. But instead, sssd-sudo.socket must be enabled. Periodt.
When SSSD is configured to use IPA as the ID provider, the sudo provider is automatically enabled β she just turns herself on, iconic. The sudo search base is configured to use the IPA native LDAP tree, which is cn=sudo,$SUFFIX. But if any other search base is defined in sssd.conf, that value will be used instead. And btw, the compat tree (ou=sudoers,$SUFFIX) is no longer required for IPA sudo functionality. We love an upgrade. π
π¦ THE SUDO RULE CACHING MECHANISM π¦
The biggest challenge when developing sudo support in SSSD was making sure that running sudo with SSSD as the data source gives you the same user experience and is as fast as sudo, while also keeping the most current set of rules possible. like, the AUDACITY of those requirements. To satisfy them, SSSD uses three kinds of updates. They're called full refresh, smart refresh and rules refresh. π
The smart refresh periodically downloads rules that are new or were modified after the last update. Its primary goal is to keep the database growing by fetching only small increments that don't generate large amounts of network traffic. little sips, not the whole pitcher. π
The full refresh simply deletes all sudo rules stored in the cache and replaces them with all rules that are stored on the server. This is used to keep the cache consistent by removing every rule which was deleted from the server. But heads up β full refresh may produce a lot of traffic, so it should be run only occasionally, depending on the size and stability of the sudo rules. it's giving heavy, use sparingly. π
The rules refresh ensures that we do not grant the user more permission than defined. It is triggered each time the user runs sudo. Rules refresh will find all rules that apply to this user, check their expiration time and redownload them if expired. And in the case that any of these rules are missing on the server, SSSD will do an out of band full refresh, because more rules (that apply to other users) may have been deleted. she's thorough like that. π
If enabled, SSSD will store only rules that can be applied to this machine. Which means rules that contain one of the following values in the sudoHost attribute:
- keyword
ALL - wildcard
- netgroup (in the form
"+netgroup") - hostname or fully qualified domain name of this machine
- one of the IP addresses of this machine
- one of the IP addresses of the network (in the form
"address/mask")
There are many configuration options that can be used to adjust the behavior. Please refer to "ldap_sudo_*" in sssd-ldap(5) and "sudo_*" in sssd.conf(5). go read those, bestie, they're the deep lore. π
β TUNING THE PERFORMANCE β
SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values that should satisfy most of our users, but the following paragraphs contain a few tips on how to fine-tune the configuration to your requirements. let's optimize, queen. π
- Index LDAP attributes. Make sure that the following LDAP attributes are indexed:
objectClass,cn,entryUSNormodifyTimestamp. - Set
ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup. - Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may consider increasing the
ldap_sudo_full_refresh_intervalandldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by settingldap_sudo_smart_refresh_interval = 0. - If you have a large number of clients, you may consider increasing the value of
ldap_sudo_random_offsetto distribute the load on the server better. spread the love, spread the load π
π SEE ALSO π
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
π AUTHORS π
The SSSD upstream β https://github.com/SSSD/sssd/ stan the upstream, they did that. π«Ά
okay and that's the whole page bestie, you ate it up π β¨ this lil masterpiece came from SSSD and it's dated 07/08/2026, filed under SSSD-SUDO(5). mwah, go configure something iconic πππ¦
π¦ where this page comes from
- fedora 43: sssd-common 2.12.0-3.fc43 Β· GPL-3.0-or-later
- fedora 44: sssd-common 2.13.1-2.fc44 Β· GPL-3.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms