sss_override - Man Page

sss_override COMMAND [options]

sss_override enables to create a client-side view and allows to change selected values of specific user and groups​. This change takes effect only on local machine​.

Overrides data are stored in the SSSD cache​. If the cache is deleted, all local overrides are lost​. Please note that after the first override is created using any of the following user-add, group-add, user-import or group-import command​. SSSD needs to be restarted to take effect​. sss_override prints message when a restart is required​.

NOTE: The options provided in this man page only work with “ldap” and “AD” “ id_provider”​. IPA overrides can be managed centrally on the IPA server​.

Argument NAME is the name of original object in all commands​. It is not possible to override uid or gid to 0​.

user-add NAME [-n,--name NAME] [-u,--uid UID] [-g,--gid GID] [-h,--home HOME] [-s,--shell SHELL] [-c,--gecos GECOS] [-x,--certificate BASE64 ENCODED CERTIFICATE]

Override attributes of an user​. Please be aware that calling this command will replace any previous override for the (NAMEd) user​.

user-del NAME

Remove user overrides​. However be aware that overridden attributes might be returned from memory cache​. Please see SSSD option memcache_timeout for more details​.

user-find [-d,--domain DOMAIN]

List all users with set overrides​. If DOMAIN parameter is set, only users from the domain are listed​.

user-show NAME

Show user overrides​.

user-import FILE

Import user overrides from FILE​. Data format is similar to standard passwd file​. The format is:

original_name:name:uid:gid:gecos:home:shell:base64_encoded_certificate

where original_name is original name of the user whose attributes should be overridden​. The rest of fields correspond to new values​. You can omit a value simply by leaving corresponding field empty​.

Examples:

ckent:superman::::::

ckent@krypton​.com::501:501:Superman:/home/earth:/bin/bash:

user-export FILE

Export all overridden attributes and store them in FILE​. See user-import for data format​.

group-add NAME [-n,--name NAME] [-g,--gid GID]

Override attributes of a group​. Please be aware that calling this command will replace any previous override for the (NAMEd) group​.

group-del NAME

Remove group overrides​. However be aware that overridden attributes might be returned from memory cache​. Please see SSSD option memcache_timeout for more details​.

group-find [-d,--domain DOMAIN]

List all groups with set overrides​. If DOMAIN parameter is set, only groups from the domain are listed​.

group-show NAME

Show group overrides​.

group-import FILE

Import group overrides from FILE​. Data format is similar to standard group file​. The format is:

original_name:name:gid

where original_name is original name of the group whose attributes should be overridden​. The rest of fields correspond to new values​. You can omit a value simply by leaving corresponding field empty​.

Examples:

admins:administrators:

Domain Users:Users:501

group-export FILE

Export all overridden attributes and store them in FILE​. See group-import for data format​.

Those options are available with all commands​.

--debug LEVEL

SSSD supports two representations for specifying the debug level​. The simplest is to specify a decimal value from 0-9, which represents enabling that level and all lower-level debug messages​. The more comprehensive option is to specify a hexadecimal bitmask to enable or disable specific levels (such as if you wish to suppress a level)​.

Currently supported debug levels:

0, 0x0010: Fatal failures​. Anything that would prevent SSSD from starting up or causes it to cease running​.

1, 0x0020: Critical failures​. An error that doesn't kill SSSD, but one that indicates that at least one major feature is not going to work properly​.

2, 0x0040: Serious failures​. An error announcing that a particular request or operation has failed​.

3, 0x0080: Minor failures​. These are the errors that would percolate down to cause the operation failure of 2​.

4, 0x0100: Configuration settings​.

5, 0x0200: Function data​.

6, 0x0400: Trace messages for operation functions​.

7, 0x1000: Trace messages for internal control functions​.

8, 0x2000: Contents of function-internal variables that may be interesting​.

9, 0x4000: Extremely low-level tracing information​.

10, 0x10000: Even more low-level libldb tracing information​. Almost never really required​.

To log required bitmask debug levels, simply add their numbers together as shown in following examples:

Example: To log fatal failures, critical failures, serious failures and function data use 0x0270​.

Example: To log fatal failures, configuration settings, function data, trace messages for internal control functions use 0x1310​.

Note: The bitmask format of debug levels was introduced in 1​.7​.0​.

Default: 0x0070 (i​.e​. fatal, critical and serious failures; corresponds to setting 2 in decimal notation)

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)

The SSSD upstream - https://github​.com/SSSD/sssd/