1SSS_OVERRIDE(8) SSSD Manual pages SSS_OVERRIDE(8)
2
6 sss_override - create local overrides of user and group attributes
7
9 sss_override COMMAND [options]
10
12 sss_override enables to create a client-side view and allows to change
13 selected values of specific user and groups. This change takes effect
14 only on local machine.
15 Overrides data are stored in the SSSD cache. If the cache is deleted,
17 all local overrides are lost. Please note that after the first override
18 is created using any of the following user-add, group-add, user-import
19 or group-import command. SSSD needs to be restarted to take effect.
20 sss_override prints message when a restart is required.
21
23 Argument NAME is the name of original object in all commands. It is not
24 possible to override uid or gid to 0.
25 user-add NAME [-n,--name NAME] [-u,--uid UID] [-g,--gid GID] [-h,--home
27 HOME] [-s,--shell SHELL] [-c,--gecos GECOS] [-x,--certificate BASE64
28 ENCODED CERTIFICATE]
29 Override attributes of an user. Please be aware that calling this
30 command will replace any previous override for the (NAMEd) user.
31 user-del NAME
33 Remove user overrides. However be aware that overridden attributes
34 might be returned from memory cache. Please see SSSD option
35 memcache_timeout for more details.
36 user-find [-d,--domain DOMAIN]
38 List all users with set overrides. If DOMAIN parameter is set, only
39 users from the domain are listed.
40 user-show NAME
42 Show user overrides.
43 user-import FILE
45 Import user overrides from FILE. Data format is similar to standard
46 passwd file. The format is:
47 original_name:name:uid:gid:gecos:home:shell:base64_encoded_certificate
49 where original_name is original name of the user whose attributes
51 should be overridden. The rest of fields correspond to new values.
52 You can omit a value simply by leaving corresponding field empty.
53 Examples:
55 ckent:superman::::::
57 ckent@krypton.com::501:501:Superman:/home/earth:/bin/bash:
59 user-export FILE
61 Export all overridden attributes and store them in FILE. See
62 user-import for data format.
63 group-add NAME [-n,--name NAME] [-g,--gid GID]
65 Override attributes of a group. Please be aware that calling this
66 command will replace any previous override for the (NAMEd) group.
67 group-del NAME
69 Remove group overrides. However be aware that overridden attributes
70 might be returned from memory cache. Please see SSSD option
71 memcache_timeout for more details.
72 group-find [-d,--domain DOMAIN]
74 List all groups with set overrides. If DOMAIN parameter is set,
75 only groups from the domain are listed.
76 group-show NAME
78 Show group overrides.
79 group-import FILE
81 Import group overrides from FILE. Data format is similar to
82 standard group file. The format is:
83 original_name:name:gid
85 where original_name is original name of the group whose attributes
87 should be overridden. The rest of fields correspond to new values.
88 You can omit a value simply by leaving corresponding field empty.
89 Examples:
91 admins:administrators:
93 Domain Users:Users:501
95 group-export FILE
97 Export all overridden attributes and store them in FILE. See
98 group-import for data format.
99
101 Those options are available with all commands.
102 --debug LEVEL
104 SSSD supports two representations for specifying the debug level.
105 The simplest is to specify a decimal value from 0-9, which
106 represents enabling that level and all lower-level debug messages.
107 The more comprehensive option is to specify a hexadecimal bitmask
108 to enable or disable specific levels (such as if you wish to
109 suppress a level).
110 Please note that each SSSD service logs into its own log file. Also
112 please note that enabling “debug_level” in the “[sssd]” section
113 only enables debugging just for the sssd process itself, not for
114 the responder or provider processes. The “debug_level” parameter
115 should be added to all sections that you wish to produce debug logs
116 from.
117 In addition to changing the log level in the config file using the
119 “debug_level” parameter, which is persistent, but requires SSSD
120 restart, it is also possible to change the debug level on the fly
121 using the sss_debuglevel(8) tool.
122 Currently supported debug levels:
124 0, 0x0010: Fatal failures. Anything that would prevent SSSD from
127 starting up or causes it to cease running.
128 1, 0x0020: Critical failures. An error that doesn´t kill the SSSD,
131 but one that indicates that at least one major feature is not going
132 to work properly.
133 2, 0x0040: Serious failures. An error announcing that a particular
136 request or operation has failed.
137 3, 0x0080: Minor failures. These are the errors that would
140 percolate down to cause the operation failure of 2.
141 4, 0x0100: Configuration settings.
144 5, 0x0200: Function data.
147 6, 0x0400: Trace messages for operation functions.
150 7, 0x1000: Trace messages for internal control functions.
153 8, 0x2000: Contents of function-internal variables that may be
156 interesting.
157 9, 0x4000: Extremely low-level tracing information.
160 To log required bitmask debug levels, simply add their numbers
162 together as shown in following examples:
163 Example: To log fatal failures, critical failures, serious failures
166 and function data use 0x0270.
167 Example: To log fatal failures, configuration settings, function
170 data, trace messages for internal control functions use 0x1310.
171 Note: The bitmask format of debug levels was introduced in 1.7.0.
174 Default: 0
177
179 sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5),
180 sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sss_cache(8), sss_debuglevel(8),
181 sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8),
182 sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8),
183 sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8),
184 sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)
185
187 The SSSD upstream - http://fedorahosted.org/sssd
188SSSD 01/15/2019 SSS_OVERRIDE(8)