sssd-sudo man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

SSSD-SUDO(5)		 File Formats and Conventions		  SSSD-SUDO(5)

NAME
       sssd-sudo - Configuring sudo with the SSSD back end

DESCRIPTION
       This manual page describes how to configure sudo(8) to work with
       sssd(8) and how SSSD caches sudo rules.

CONFIGURING SUDO TO COOPERATE WITH SSSD
       To enable SSSD as a source for sudo rules, add sss to the sudoers entry
       in nsswitch.conf(5).

       For example, to configure sudo to first lookup rules in the standard
       sudoers(5) file (which should contain rules that apply to local users)
       and then in SSSD, the nsswitch.conf file should contain the following
       line:

	   sudoers: files sss

       More information about configuring the sudoers search order from the
       nsswitch.conf file as well as information about the LDAP schema that is
       used to store sudo rules in the directory can be found in
       sudoers.ldap(5).

CONFIGURING SSSD TO FETCH SUDO RULES
       The following example shows how to configure SSSD to download sudo
       rules from an LDAP server.

	   [sssd]
	   config_file_version = 2
	   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

       The following example illustrates setting up SSSD to download sudo
       rules from an IPA server. It is necessary to use the LDAP provider and
       set appropriate connection parameters to authenticate correctly against
       the IPA server, because SSSD does not have native support of IPA
       provider for sudo yet.

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

	   [domain/EXAMPLE]
	   id_provider = ipa
	   ipa_domain = example.com
	   ipa_server = ipa.example.com
	   ldap_tls_cacert = /etc/ipa/ca.crt

	   sudo_provider = ldap
	   ldap_uri = ldap://ipa.example.com
	   ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
	   ldap_sasl_mech = GSSAPI
	   ldap_sasl_authid = host/hostname.example.com
	   ldap_sasl_realm = EXAMPLE.COM
	   krb5_server = ipa.example.com

THE SUDO RULE CACHING MECHANISM
       The biggest challenge, when developing sudo support in SSSD, was to
       ensure that running sudo with SSSD as the data source provides the same
       user experience and is as fast as sudo but keeps providing the most
       current set of rules as possible. To satisfy these requirements, SSSD
       uses three kinds of updates. They are referred to as 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 do not generate
       large amounts of network traffic.

       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. However, full refresh may produce a lot of
       traffic and thus it should be run only occasionally depending on the
       size and stability of the sudo rules.

       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. In the case that any of
       these rules are missing on the server, the SSSD will do an out of band
       full refresh because more rules (that apply to other users) may have
       been deleted.

       If enabled, SSSD will store only rules that can be applied to this
       machine. This means rules that contain one of the following values in
       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).

SEE ALSO
       sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5),
       sssd-ipa(5), sssd-ad(5), sssd-sudo(5),sss_cache(8), sss_debuglevel(8),
       sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8),
       sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8),
       sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8),
       sss_ssh_knowhostsproxy(8),pam_sss(8).

AUTHORS
       The SSSD upstream - http://fedorahosted.org/sssd

SSSD				  04/23/2013			  SSSD-SUDO(5)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net