1: SUDOERS.LDAP(1m) System Manager's Manual SUDOERS.LDAP(1m)
2:
3: NNAAMMEE
4: ssuuddooeerrss..llddaapp - sudo LDAP configuration
5:
6: DDEESSCCRRIIPPTTIIOONN
7: In addition to the standard _s_u_d_o_e_r_s file, ssuuddoo may be configured via
8: LDAP. This can be especially useful for synchronizing _s_u_d_o_e_r_s in a
9: large, distributed environment.
10:
11: Using LDAP for _s_u_d_o_e_r_s has several benefits:
12:
13: oo ssuuddoo no longer needs to read _s_u_d_o_e_r_s in its entirety. When LDAP is
14: used, there are only two or three LDAP queries per invocation. This
15: makes it especially fast and particularly usable in LDAP
16: environments.
17:
18: oo ssuuddoo no longer exits if there is a typo in _s_u_d_o_e_r_s. It is not
19: possible to load LDAP data into the server that does not conform to
20: the sudoers schema, so proper syntax is guaranteed. It is still
21: possible to have typos in a user or host name, but this will not
22: prevent ssuuddoo from running.
23:
24: oo It is possible to specify per-entry options that override the global
25: default options. _/_e_t_c_/_s_u_d_o_e_r_s only supports default options and
26: limited options associated with user/host/commands/aliases. The
27: syntax is complicated and can be difficult for users to understand.
28: Placing the options directly in the entry is more natural.
29:
30: oo The vviissuuddoo program is no longer needed. vviissuuddoo provides locking and
31: syntax checking of the _/_e_t_c_/_s_u_d_o_e_r_s file. Since LDAP updates are
32: atomic, locking is no longer necessary. Because syntax is checked
33: when the data is inserted into LDAP, there is no need for a
34: specialized tool to check syntax.
35:
36: Another major difference between LDAP and file-based _s_u_d_o_e_r_s is that in
37: LDAP, ssuuddoo-specific Aliases are not supported.
38:
39: For the most part, there is really no need for ssuuddoo-specific Aliases.
40: Unix groups, non-Unix groups (via the _g_r_o_u_p___p_l_u_g_i_n) or user netgroups can
41: be used in place of User_Aliases and Runas_Aliases. Host netgroups can
42: be used in place of Host_Aliases. Since groups and netgroups can also be
43: stored in LDAP there is no real need for ssuuddoo-specific aliases.
44:
45: Cmnd_Aliases are not really required either since it is possible to have
46: multiple users listed in a sudoRole. Instead of defining a Cmnd_Alias
47: that is referenced by multiple users, one can create a sudoRole that
48: contains the commands and assign multiple users to it.
49:
50: SSUUDDOOeerrss LLDDAAPP ccoonnttaaiinneerr
51: The _s_u_d_o_e_r_s configuration is contained in the ou=SUDOers LDAP container.
52:
53: Sudo first looks for the cn=default entry in the SUDOers container. If
54: found, the multi-valued sudoOption attribute is parsed in the same manner
55: as a global Defaults line in _/_e_t_c_/_s_u_d_o_e_r_s. In the following example, the
56: SSH_AUTH_SOCK variable will be preserved in the environment for all
57: users.
58:
59: dn: cn=defaults,ou=SUDOers,dc=example,dc=com
60: objectClass: top
61: objectClass: sudoRole
62: cn: defaults
63: description: Default sudoOption's go here
64: sudoOption: env_keep+=SSH_AUTH_SOCK
65:
66: The equivalent of a sudoer in LDAP is a sudoRole. It consists of the
67: following attributes:
68:
69: ssuuddooUUsseerr
70: A user name, user ID (prefixed with `#'), Unix group name or ID
71: (prefixed with `%' or `%#' respectively), user netgroup (prefixed
72: with `+'), or non-Unix group name or ID (prefixed with `%:' or
73: `%:#' respectively). Non-Unix group support is only available when
74: an appropriate _g_r_o_u_p___p_l_u_g_i_n is defined in the global _d_e_f_a_u_l_t_s
75: sudoRole object.
76:
77: ssuuddooHHoosstt
78: A host name, IP address, IP network, or host netgroup (prefixed
79: with a `+'). The special value ALL will match any host.
80:
81: ssuuddooCCoommmmaanndd
82: A fully-qualified Unix command name with optional command line
83: arguments, potentially including globbing characters (aka wild
84: cards). If a command name is preceded by an exclamation point,
85: `!', the user will be prohibited from running that command.
86:
87: The built-in command ``sudoedit'' is used to permit a user to run
88: ssuuddoo with the --ee option (or as ssuuddooeeddiitt). It may take command line
89: arguments just as a normal command does. Note that ``sudoedit'' is
90: a command built into ssuuddoo itself and must be specified in without a
91: leading path.
92:
93: The special value ALL will match any command.
94:
95: If a command name is prefixed with a SHA-2 digest, it will only be
96: allowed if the digest matches. This may be useful in situations
97: where the user invoking ssuuddoo has write access to the command or its
98: parent directory. The following digest formats are supported:
99: sha224, sha256, sha384 and sha512. The digest name must be
100: followed by a colon (`:') and then the actual digest, in either hex
101: or base64 format. For example, given the following value for
102: sudoCommand:
103:
104: sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
105:
106: The user may only run _/_b_i_n_/_l_s if its sha224 digest matches the
107: specified value. Command digests are only supported by version
108: 1.8.7 or higher.
109:
110: ssuuddooOOppttiioonn
111: Identical in function to the global options described above, but
112: specific to the sudoRole in which it resides.
113:
114: ssuuddooRRuunnAAssUUsseerr
115: A user name or uid (prefixed with `#') that commands may be run as
116: or a Unix group (prefixed with a `%') or user netgroup (prefixed
117: with a `+') that contains a list of users that commands may be run
118: as. The special value ALL will match any user.
119:
120: The sudoRunAsUser attribute is only available in ssuuddoo versions
121: 1.7.0 and higher. Older versions of ssuuddoo use the sudoRunAs
122: attribute instead.
123:
124: ssuuddooRRuunnAAssGGrroouupp
125: A Unix group or gid (prefixed with `#') that commands may be run
126: as. The special value ALL will match any group.
127:
128: The sudoRunAsGroup attribute is only available in ssuuddoo versions
129: 1.7.0 and higher.
130:
131: ssuuddooNNoottBBeeffoorree
132: A timestamp in the form yyyymmddHHMMSSZ that can be used to provide
133: a start date/time for when the sudoRole will be valid. If multiple
134: sudoNotBefore entries are present, the earliest is used. Note that
135: timestamps must be in Coordinated Universal Time (UTC), not the
136: local timezone. The minute and seconds portions are optional, but
137: some LDAP servers require that they be present (contrary to the
138: RFC).
139:
140: The sudoNotBefore attribute is only available in ssuuddoo versions
141: 1.7.5 and higher and must be explicitly enabled via the
142: SSUUDDOOEERRSS__TTIIMMEEDD option in _/_e_t_c_/_l_d_a_p_._c_o_n_f.
143:
144: ssuuddooNNoottAAfftteerr
145: A timestamp in the form yyyymmddHHMMSSZ that indicates an
146: expiration date/time, after which the sudoRole will no longer be
147: valid. If multiple sudoNotBefore entries are present, the last one
148: is used. Note that timestamps must be in Coordinated Universal
149: Time (UTC), not the local timezone. The minute and seconds
150: portions are optional, but some LDAP servers require that they be
151: present (contrary to the RFC).
152:
153: The sudoNotAfter attribute is only available in ssuuddoo versions 1.7.5
154: and higher and must be explicitly enabled via the SSUUDDOOEERRSS__TTIIMMEEDD
155: option in _/_e_t_c_/_l_d_a_p_._c_o_n_f.
156:
157: ssuuddooOOrrddeerr
158: The sudoRole entries retrieved from the LDAP directory have no
159: inherent order. The sudoOrder attribute is an integer (or floating
160: point value for LDAP servers that support it) that is used to sort
161: the matching entries. This allows LDAP-based sudoers entries to
162: more closely mimic the behavior of the sudoers file, where the of
163: the entries influences the result. If multiple entries match, the
164: entry with the highest sudoOrder attribute is chosen. This
165: corresponds to the ``last match'' behavior of the sudoers file. If
166: the sudoOrder attribute is not present, a value of 0 is assumed.
167:
168: The sudoOrder attribute is only available in ssuuddoo versions 1.7.5
169: and higher.
170:
171: Each attribute listed above should contain a single value, but there may
172: be multiple instances of each attribute type. A sudoRole must contain at
173: least one sudoUser, sudoHost and sudoCommand.
174:
175: The following example allows users in group wheel to run any command on
176: any host via ssuuddoo:
177:
178: dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
179: objectClass: top
180: objectClass: sudoRole
181: cn: %wheel
182: sudoUser: %wheel
183: sudoHost: ALL
184: sudoCommand: ALL
185:
186: AAnnaattoommyy ooff LLDDAAPP ssuuddooeerrss llooookkuupp
187: When looking up a sudoer using LDAP there are only two or three LDAP
188: queries per invocation. The first query is to parse the global options.
189: The second is to match against the user's name and the groups that the
190: user belongs to. (The special ALL tag is matched in this query too.) If
191: no match is returned for the user's name and groups, a third query
192: returns all entries containing user netgroups and checks to see if the
193: user belongs to any of them.
194:
195: If timed entries are enabled with the SSUUDDOOEERRSS__TTIIMMEEDD configuration
196: directive, the LDAP queries include a sub-filter that limits retrieval to
197: entries that satisfy the time constraints, if any.
198:
199: DDiiffffeerreenncceess bbeettwweeeenn LLDDAAPP aanndd nnoonn--LLDDAAPP ssuuddooeerrss
200: There are some subtle differences in the way sudoers is handled once in
201: LDAP. Probably the biggest is that according to the RFC, LDAP ordering
202: is arbitrary and you cannot expect that Attributes and Entries are
203: returned in any specific order.
204:
205: The order in which different entries are applied can be controlled using
206: the sudoOrder attribute, but there is no way to guarantee the order of
207: attributes within a specific entry. If there are conflicting command
208: rules in an entry, the negative takes precedence. This is called
209: paranoid behavior (not necessarily the most specific match).
210:
211: Here is an example:
212:
213: # /etc/sudoers:
214: # Allow all commands except shell
215: johnny ALL=(root) ALL,!/bin/sh
216: # Always allows all commands because ALL is matched last
217: puddles ALL=(root) !/bin/sh,ALL
218:
219: # LDAP equivalent of johnny
220: # Allows all commands except shell
221: dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
222: objectClass: sudoRole
223: objectClass: top
224: cn: role1
225: sudoUser: johnny
226: sudoHost: ALL
227: sudoCommand: ALL
228: sudoCommand: !/bin/sh
229:
230: # LDAP equivalent of puddles
231: # Notice that even though ALL comes last, it still behaves like
232: # role1 since the LDAP code assumes the more paranoid configuration
233: dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
234: objectClass: sudoRole
235: objectClass: top
236: cn: role2
237: sudoUser: puddles
238: sudoHost: ALL
239: sudoCommand: !/bin/sh
240: sudoCommand: ALL
241:
242: Another difference is that negations on the Host, User or Runas are
243: currently ignored. For example, the following attributes do not behave
244: the way one might expect.
245:
246: # does not match all but joe
247: # rather, does not match anyone
248: sudoUser: !joe
249:
250: # does not match all but joe
251: # rather, matches everyone including Joe
252: sudoUser: ALL
253: sudoUser: !joe
254:
255: # does not match all but web01
256: # rather, matches all hosts including web01
257: sudoHost: ALL
258: sudoHost: !web01
259:
260: SSuuddooeerrss sscchheemmaa
261: In order to use ssuuddoo's LDAP support, the ssuuddoo schema must be installed on
262: your LDAP server. In addition, be sure to index the sudoUser attribute.
263:
264: Three versions of the schema: one for OpenLDAP servers (_s_c_h_e_m_a_._O_p_e_n_L_D_A_P),
265: one for Netscape-derived servers (_s_c_h_e_m_a_._i_P_l_a_n_e_t), and one for Microsoft
266: Active Directory (_s_c_h_e_m_a_._A_c_t_i_v_e_D_i_r_e_c_t_o_r_y) may be found in the ssuuddoo
267: distribution.
268:
269: The schema for ssuuddoo in OpenLDAP form is also included in the _E_X_A_M_P_L_E_S
270: section.
271:
272: CCoonnffiigguurriinngg llddaapp..ccoonnff
273: Sudo reads the _/_e_t_c_/_l_d_a_p_._c_o_n_f file for LDAP-specific configuration.
274: Typically, this file is shared between different LDAP-aware clients. As
275: such, most of the settings are not ssuuddoo-specific. Note that ssuuddoo parses
276: _/_e_t_c_/_l_d_a_p_._c_o_n_f itself and may support options that differ from those
277: described in the system's ldap.conf(1m) manual. The path to _l_d_a_p_._c_o_n_f may
278: be overridden via the _l_d_a_p___c_o_n_f plugin argument in sudo.conf(4).
279:
280: Also note that on systems using the OpenLDAP libraries, default values
281: specified in _/_e_t_c_/_o_p_e_n_l_d_a_p_/_l_d_a_p_._c_o_n_f or the user's _._l_d_a_p_r_c files are not
282: used.
283:
284: Only those options explicitly listed in _/_e_t_c_/_l_d_a_p_._c_o_n_f as being supported
285: by ssuuddoo are honored. Configuration options are listed below in upper
286: case but are parsed in a case-independent manner.
287:
288: The pound sign (`#') is used to indicate a comment. Both the comment
289: character and any text after it, up to the end of the line, are ignored.
290: Long lines can be continued with a backslash (`\') as the last character
291: on the line. Note that leading white space is removed from the beginning
292: of lines even when the continuation character is used.
293:
294: UURRII _l_d_a_p_[_s_]_:_/_/_[_h_o_s_t_n_a_m_e_[_:_p_o_r_t_]_] _._._.
295: Specifies a white space-delimited list of one or more URIs
296: describing the LDAP server(s) to connect to. The _p_r_o_t_o_c_o_l may be
297: either _l_d_a_p _l_d_a_p_s, the latter being for servers that support TLS
298: (SSL) encryption. If no _p_o_r_t is specified, the default is port 389
299: for ldap:// or port 636 for ldaps://. If no _h_o_s_t_n_a_m_e is specified,
300: ssuuddoo will connect to _l_o_c_a_l_h_o_s_t. Multiple UURRII lines are treated
301: identically to a UURRII line containing multiple entries. Only
302: systems using the OpenSSL libraries support the mixing of ldap://
303: and ldaps:// URIs. Both the Netscape-derived and Tivoli LDAP
304: libraries used on most commercial versions of Unix are only capable
305: of supporting one or the other.
306:
307: HHOOSSTT _n_a_m_e_[_:_p_o_r_t_] _._._.
308: If no UURRII is specified, the HHOOSSTT parameter specifies a white space-
309: delimited list of LDAP servers to connect to. Each host may
310: include an optional _p_o_r_t separated by a colon (`:'). The HHOOSSTT
311: parameter is deprecated in favor of the UURRII specification and is
312: included for backwards compatibility.
313:
314: PPOORRTT _p_o_r_t___n_u_m_b_e_r
315: If no UURRII is specified, the PPOORRTT parameter specifies the default
316: port to connect to on the LDAP server if a HHOOSSTT parameter does not
317: specify the port itself. If no PPOORRTT parameter is used, the default
318: is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
319: PPOORRTT parameter is deprecated in favor of the UURRII specification and
320: is included for backwards compatibility.
321:
322: BBIINNDD__TTIIMMEELLIIMMIITT _s_e_c_o_n_d_s
323: The BBIINNDD__TTIIMMEELLIIMMIITT parameter specifies the amount of time, in
324: seconds, to wait while trying to connect to an LDAP server. If
325: multiple UURRIIs or HHOOSSTTs are specified, this is the amount of time to
326: wait before trying the next one in the list.
327:
328: NNEETTWWOORRKK__TTIIMMEEOOUUTT _s_e_c_o_n_d_s
329: An alias for BBIINNDD__TTIIMMEELLIIMMIITT for OpenLDAP compatibility.
330:
331: TTIIMMEELLIIMMIITT _s_e_c_o_n_d_s
332: The TTIIMMEELLIIMMIITT parameter specifies the amount of time, in seconds,
333: to wait for a response to an LDAP query.
334:
335: TTIIMMEEOOUUTT _s_e_c_o_n_d_s
336: The TTIIMMEEOOUUTT parameter specifies the amount of time, in seconds, to
337: wait for a response from the various LDAP APIs.
338:
339: SSUUDDOOEERRSS__BBAASSEE _b_a_s_e
340: The base DN to use when performing ssuuddoo LDAP queries. Typically
341: this is of the form ou=SUDOers,dc=example,dc=com for the domain
342: example.com. Multiple SSUUDDOOEERRSS__BBAASSEE lines may be specified, in
343: which case they are queried in the order specified.
344:
345: SSUUDDOOEERRSS__SSEEAARRCCHH__FFIILLTTEERR _l_d_a_p___f_i_l_t_e_r
346: An LDAP filter which is used to restrict the set of records
347: returned when performing a ssuuddoo LDAP query. Typically, this is of
348: the form attribute=value or
349: (&(attribute=value)(attribute2=value2)).
350:
351: SSUUDDOOEERRSS__TTIIMMEEDD _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
352: Whether or not to evaluate the sudoNotBefore and sudoNotAfter
353: attributes that implement time-dependent sudoers entries.
354:
355: SSUUDDOOEERRSS__DDEEBBUUGG _d_e_b_u_g___l_e_v_e_l
356: This sets the debug level for ssuuddoo LDAP queries. Debugging
357: information is printed to the standard error. A value of 1 results
358: in a moderate amount of debugging information. A value of 2 shows
359: the results of the matches themselves. This parameter should not
360: be set in a production environment as the extra information is
361: likely to confuse users.
362:
363: The SSUUDDOOEERRSS__DDEEBBUUGG parameter is deprecated and will be removed in a
364: future release. The same information is now logged via the ssuuddoo
365: debugging framework using the ``ldap'' subsystem at priorities _d_i_a_g
366: and _i_n_f_o for _d_e_b_u_g___l_e_v_e_l values 1 and 2 respectively. See the
367: sudo.conf(4) manual for details on how to configure ssuuddoo debugging.
368:
369: BBIINNDDDDNN _D_N
370: The BBIINNDDDDNN parameter specifies the identity, in the form of a
371: Distinguished Name (DN), to use when performing LDAP operations.
372: If not specified, LDAP operations are performed with an anonymous
373: identity. By default, most LDAP servers will allow anonymous
374: access.
375:
376: BBIINNDDPPWW _s_e_c_r_e_t
377: The BBIINNDDPPWW parameter specifies the password to use when performing
378: LDAP operations. This is typically used in conjunction with the
379: BBIINNDDDDNN parameter.
380:
381: RROOOOTTBBIINNDDDDNN _D_N
382: The RROOOOTTBBIINNDDDDNN parameter specifies the identity, in the form of a
383: Distinguished Name (DN), to use when performing privileged LDAP
384: operations, such as _s_u_d_o_e_r_s queries. The password corresponding to
385: the identity should be stored in the or the path specified by the
386: _l_d_a_p___s_e_c_r_e_t plugin argument in sudo.conf(4), which defaults to
387: _/_e_t_c_/_l_d_a_p_._s_e_c_r_e_t. If no RROOOOTTBBIINNDDDDNN is specified, the BBIINNDDDDNN
388: identity is used (if any).
389:
390: LLDDAAPP__VVEERRSSIIOONN _n_u_m_b_e_r
391: The version of the LDAP protocol to use when connecting to the
392: server. The default value is protocol version 3.
393:
394: SSSSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
395: If the SSSSLL parameter is set to on, true or yes, TLS (SSL)
396: encryption is always used when communicating with the LDAP server.
397: Typically, this involves connecting to the server on port 636
398: (ldaps).
399:
400: SSSSLL _s_t_a_r_t___t_l_s
401: If the SSSSLL parameter is set to start_tls, the LDAP server
402: connection is initiated normally and TLS encryption is begun before
403: the bind credentials are sent. This has the advantage of not
404: requiring a dedicated port for encrypted communications. This
405: parameter is only supported by LDAP servers that honor the
406: _s_t_a_r_t___t_l_s extension, such as the OpenLDAP and Tivoli Directory
407: servers.
408:
409: TTLLSS__CCHHEECCKKPPEEEERR _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
410: If enabled, TTLLSS__CCHHEECCKKPPEEEERR will cause the LDAP server's TLS
411: certificated to be verified. If the server's TLS certificate
412: cannot be verified (usually because it is signed by an unknown
413: certificate authority), ssuuddoo will be unable to connect to it. If
414: TTLLSS__CCHHEECCKKPPEEEERR is disabled, no check is made. Note that disabling
415: the check creates an opportunity for man-in-the-middle attacks
416: since the server's identity will not be authenticated. If
417: possible, the CA's certificate should be installed locally so it
418: can be verified. This option is not supported by the Tivoli
419: Directory Server LDAP libraries.
420:
421: TTLLSS__CCAACCEERRTT _f_i_l_e _n_a_m_e
422: An alias for TTLLSS__CCAACCEERRTTFFIILLEE for OpenLDAP compatibility.
423:
424: TTLLSS__CCAACCEERRTTFFIILLEE _f_i_l_e _n_a_m_e
425: The path to a certificate authority bundle which contains the
426: certificates for all the Certificate Authorities the client knows
427: to be valid, e.g. _/_e_t_c_/_s_s_l_/_c_a_-_b_u_n_d_l_e_._p_e_m. This option is only
428: supported by the OpenLDAP libraries. Netscape-derived LDAP
429: libraries use the same certificate database for CA and client
430: certificates (see TTLLSS__CCEERRTT).
431:
432: TTLLSS__CCAACCEERRTTDDIIRR _d_i_r_e_c_t_o_r_y
433: Similar to TTLLSS__CCAACCEERRTTFFIILLEE but instead of a file, it is a directory
434: containing individual Certificate Authority certificates, e.g.
435: _/_e_t_c_/_s_s_l_/_c_e_r_t_s. The directory specified by TTLLSS__CCAACCEERRTTDDIIRR is
436: checked after TTLLSS__CCAACCEERRTTFFIILLEE. This option is only supported by the
437: OpenLDAP libraries.
438:
439: TTLLSS__CCEERRTT _f_i_l_e _n_a_m_e
440: The path to a file containing the client certificate which can be
441: used to authenticate the client to the LDAP server. The
442: certificate type depends on the LDAP libraries used.
443:
444: OpenLDAP:
445: tls_cert /etc/ssl/client_cert.pem
446:
447: Netscape-derived:
448: tls_cert /var/ldap/cert7.db
449:
450: Tivoli Directory Server:
451: Unused, the key database specified by TTLLSS__KKEEYY contains both
452: keys and certificates.
453:
454: When using Netscape-derived libraries, this file may also
455: contain Certificate Authority certificates.
456:
457: TTLLSS__KKEEYY _f_i_l_e _n_a_m_e
458: The path to a file containing the private key which matches the
459: certificate specified by TTLLSS__CCEERRTT. The private key must not be
460: password-protected. The key type depends on the LDAP libraries
461: used.
462:
463: OpenLDAP:
464: tls_key /etc/ssl/client_key.pem
465:
466: Netscape-derived:
467: tls_key /var/ldap/key3.db
468:
469: Tivoli Directory Server:
470: tls_key /usr/ldap/ldapkey.kdb
471: When using Tivoli LDAP libraries, this file may also contain
472: Certificate Authority and client certificates and may be encrypted.
473:
474: TTLLSS__KKEEYYPPWW _s_e_c_r_e_t
475: The TTLLSS__KKEEYYPPWW contains the password used to decrypt the key
476: database on clients using the Tivoli Directory Server LDAP library.
477: This should be a simple string without quotes. The password may
478: not include the comment character (`#') and escaping of special
479: characters with a backslash (`\') is not supported. If this option
480: is used, _/_e_t_c_/_l_d_a_p_._c_o_n_f must not be world-readable to avoid
481: exposing the password. Alternately, a _s_t_a_s_h _f_i_l_e can be used to
482: store the password in encrypted form (see below).
483:
484: If no TTLLSS__KKEEYYPPWW is specified, a _s_t_a_s_h _f_i_l_e will be used if it
485: exists. The _s_t_a_s_h _f_i_l_e must have the same path as the file
486: specified by TTLLSS__KKEEYY, but use a .sth file extension instead of
487: .kdb, e.g. ldapkey.sth. The default ldapkey.kdb that ships with
488: Tivoli Directory Server is encrypted with the password
489: ssl_password. The _g_s_k_8_c_a_p_i_c_m_d utility can be used to manage the
490: key database and create a _s_t_a_s_h _f_i_l_e. This option is only
491: supported by the Tivoli LDAP libraries.
492:
493: TTLLSS__RRAANNDDFFIILLEE _f_i_l_e _n_a_m_e
494: The TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an entropy source
495: for systems that lack a random device. It is generally used in
496: conjunction with _p_r_n_g_d or _e_g_d. This option is only supported by
497: the OpenLDAP libraries.
498:
499: TTLLSS__CCIIPPHHEERRSS _c_i_p_h_e_r _l_i_s_t
500: The TTLLSS__CCIIPPHHEERRSS parameter allows the administer to restrict which
501: encryption algorithms may be used for TLS (SSL) connections. See
502: the OpenLDAP or Tivoli Directory Server manual for a list of valid
503: ciphers. This option is not supported by Netscape-derived
504: libraries.
505:
506: UUSSEE__SSAASSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
507: Enable UUSSEE__SSAASSLL for LDAP servers that support SASL authentication.
508:
509: SSAASSLL__AAUUTTHH__IIDD _i_d_e_n_t_i_t_y
510: The SASL user name to use when connecting to the LDAP server. By
511: default, ssuuddoo will use an anonymous connection.
512:
513: RROOOOTTUUSSEE__SSAASSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
514: Enable RROOOOTTUUSSEE__SSAASSLL to enable SASL authentication when connecting
515: to an LDAP server from a privileged process, such as ssuuddoo.
516:
517: RROOOOTTSSAASSLL__AAUUTTHH__IIDD _i_d_e_n_t_i_t_y
518: The SASL user name to use when RROOOOTTUUSSEE__SSAASSLL is enabled.
519:
520: SSAASSLL__SSEECCPPRROOPPSS _n_o_n_e_/_p_r_o_p_e_r_t_i_e_s
521: SASL security properties or _n_o_n_e for no properties. See the SASL
522: programmer's manual for details.
523:
524: KKRRBB55__CCCCNNAAMMEE _f_i_l_e _n_a_m_e
525: The path to the Kerberos 5 credential cache to use when
526: authenticating with the remote server.
527:
528: DDEERREEFF _n_e_v_e_r_/_s_e_a_r_c_h_i_n_g_/_f_i_n_d_i_n_g_/_a_l_w_a_y_s
529: How alias dereferencing is to be performed when searching. See the
530: ldap.conf(1m) manual for a full description of this option.
531:
532: See the _l_d_a_p_._c_o_n_f entry in the _E_X_A_M_P_L_E_S section.
533:
534: CCoonnffiigguurriinngg nnsssswwiittcchh..ccoonnff
535: Unless it is disabled at build time, ssuuddoo consults the Name Service
536: Switch file, _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f, to specify the _s_u_d_o_e_r_s search order.
537: Sudo looks for a line beginning with sudoers: and uses this to determine
538: the search order. Note that ssuuddoo does not stop searching after the first
539: match and later matches take precedence over earlier ones. The following
540: sources are recognized:
541:
542: files read sudoers from _/_e_t_c_/_s_u_d_o_e_r_s
543: ldap read sudoers from LDAP
544:
545: In addition, the entry [NOTFOUND=return] will short-circuit the search if
546: the user was not found in the preceding source.
547:
548: To consult LDAP first followed by the local sudoers file (if it exists),
549: use:
550:
551: sudoers: ldap files
552:
553: The local _s_u_d_o_e_r_s file can be ignored completely by using:
554:
555: sudoers: ldap
556:
557: If the _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f file is not present or there is no sudoers
558: line, the following default is assumed:
559:
560: sudoers: files
561:
562: Note that _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f is supported even when the underlying
563: operating system does not use an nsswitch.conf file, except on AIX (see
564: below).
565:
566: CCoonnffiigguurriinngg nneettssvvcc..ccoonnff
567: On AIX systems, the _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f file is consulted instead of
568: _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f. ssuuddoo simply treats _n_e_t_s_v_c_._c_o_n_f as a variant of
569: _n_s_s_w_i_t_c_h_._c_o_n_f; information in the previous section unrelated to the file
570: format itself still applies.
571:
572: To consult LDAP first followed by the local sudoers file (if it exists),
573: use:
574:
575: sudoers = ldap, files
576:
577: The local _s_u_d_o_e_r_s file can be ignored completely by using:
578:
579: sudoers = ldap
580:
581: To treat LDAP as authoritative and only use the local sudoers file if the
582: user is not present in LDAP, use:
583:
584: sudoers = ldap = auth, files
585:
586: Note that in the above example, the auth qualifier only affects user
587: lookups; both LDAP and _s_u_d_o_e_r_s will be queried for Defaults entries.
588:
589: If the _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f file is not present or there is no sudoers line,
590: the following default is assumed:
591:
592: sudoers = files
593:
594: FFIILLEESS
595: _/_e_t_c_/_l_d_a_p_._c_o_n_f LDAP configuration file
596:
597: _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f determines sudoers source order
598:
599: _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f determines sudoers source order on AIX
600:
601: EEXXAAMMPPLLEESS
602: EExxaammppllee llddaapp..ccoonnff
603: # Either specify one or more URIs or one or more host:port pairs.
604: # If neither is specified sudo will default to localhost, port 389.
605: #
606: #host ldapserver
607: #host ldapserver1 ldapserver2:390
608: #
609: # Default port if host is specified without one, defaults to 389.
610: #port 389
611: #
612: # URI will override the host and port settings.
613: uri ldap://ldapserver
614: #uri ldaps://secureldapserver
615: #uri ldaps://secureldapserver ldap://ldapserver
616: #
617: # The amount of time, in seconds, to wait while trying to connect to
618: # an LDAP server.
619: bind_timelimit 30
620: #
621: # The amount of time, in seconds, to wait while performing an LDAP query.
622: timelimit 30
623: #
624: # Must be set or sudo will ignore LDAP; may be specified multiple times.
625: sudoers_base ou=SUDOers,dc=example,dc=com
626: #
627: # verbose sudoers matching from ldap
628: #sudoers_debug 2
629: #
630: # Enable support for time-based entries in sudoers.
631: #sudoers_timed yes
632: #
633: # optional proxy credentials
634: #binddn <who to search as>
635: #bindpw <password>
636: #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
637: #
638: # LDAP protocol version, defaults to 3
639: #ldap_version 3
640: #
641: # Define if you want to use an encrypted LDAP connection.
642: # Typically, you must also set the port to 636 (ldaps).
643: #ssl on
644: #
645: # Define if you want to use port 389 and switch to
646: # encryption before the bind credentials are sent.
647: # Only supported by LDAP servers that support the start_tls
648: # extension such as OpenLDAP.
649: #ssl start_tls
650: #
651: # Additional TLS options follow that allow tweaking of the
652: # SSL/TLS connection.
653: #
654: #tls_checkpeer yes # verify server SSL certificate
655: #tls_checkpeer no # ignore server SSL certificate
656: #
657: # If you enable tls_checkpeer, specify either tls_cacertfile
658: # or tls_cacertdir. Only supported when using OpenLDAP.
659: #
660: #tls_cacertfile /etc/certs/trusted_signers.pem
661: #tls_cacertdir /etc/certs
662: #
663: # For systems that don't have /dev/random
664: # use this along with PRNGD or EGD.pl to seed the
665: # random number pool to generate cryptographic session keys.
666: # Only supported when using OpenLDAP.
667: #
668: #tls_randfile /etc/egd-pool
669: #
670: # You may restrict which ciphers are used. Consult your SSL
671: # documentation for which options go here.
672: # Only supported when using OpenLDAP.
673: #
674: #tls_ciphers <cipher-list>
675: #
676: # Sudo can provide a client certificate when communicating to
677: # the LDAP server.
678: # Tips:
679: # * Enable both lines at the same time.
680: # * Do not password protect the key file.
681: # * Ensure the keyfile is only readable by root.
682: #
683: # For OpenLDAP:
684: #tls_cert /etc/certs/client_cert.pem
685: #tls_key /etc/certs/client_key.pem
686: #
687: # For SunONE or iPlanet LDAP, tls_cert and tls_key may specify either
688: # a directory, in which case the files in the directory must have the
689: # default names (e.g. cert8.db and key4.db), or the path to the cert
690: # and key files themselves. However, a bug in version 5.0 of the LDAP
691: # SDK will prevent specific file names from working. For this reason
692: # it is suggested that tls_cert and tls_key be set to a directory,
693: # not a file name.
694: #
695: # The certificate database specified by tls_cert may contain CA certs
696: # and/or the client's cert. If the client's cert is included, tls_key
697: # should be specified as well.
698: # For backward compatibility, "sslpath" may be used in place of tls_cert.
699: #tls_cert /var/ldap
700: #tls_key /var/ldap
701: #
702: # If using SASL authentication for LDAP (OpenSSL)
703: # use_sasl yes
704: # sasl_auth_id <SASL user name>
705: # rootuse_sasl yes
706: # rootsasl_auth_id <SASL user name for root access>
707: # sasl_secprops none
708: # krb5_ccname /etc/.ldapcache
709:
710: SSuuddoo sscchheemmaa ffoorr OOppeennLLDDAAPP
711: The following schema, in OpenLDAP format, is included with ssuuddoo source
712: and binary distributions as _s_c_h_e_m_a_._O_p_e_n_L_D_A_P. Simply copy it to the
713: schema directory (e.g. _/_e_t_c_/_o_p_e_n_l_d_a_p_/_s_c_h_e_m_a), add the proper include line
714: in _s_l_a_p_d_._c_o_n_f and restart ssllaappdd.
715:
716: attributetype ( 1.3.6.1.4.1.15953.9.1.1
717: NAME 'sudoUser'
718: DESC 'User(s) who may run sudo'
719: EQUALITY caseExactIA5Match
720: SUBSTR caseExactIA5SubstringsMatch
721: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
722:
723: attributetype ( 1.3.6.1.4.1.15953.9.1.2
724: NAME 'sudoHost'
725: DESC 'Host(s) who may run sudo'
726: EQUALITY caseExactIA5Match
727: SUBSTR caseExactIA5SubstringsMatch
728: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
729:
730: attributetype ( 1.3.6.1.4.1.15953.9.1.3
731: NAME 'sudoCommand'
732: DESC 'Command(s) to be executed by sudo'
733: EQUALITY caseExactIA5Match
734: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
735:
736: attributetype ( 1.3.6.1.4.1.15953.9.1.4
737: NAME 'sudoRunAs'
738: DESC 'User(s) impersonated by sudo'
739: EQUALITY caseExactIA5Match
740: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
741:
742: attributetype ( 1.3.6.1.4.1.15953.9.1.5
743: NAME 'sudoOption'
744: DESC 'Options(s) followed by sudo'
745: EQUALITY caseExactIA5Match
746: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
747:
748: attributetype ( 1.3.6.1.4.1.15953.9.1.6
749: NAME 'sudoRunAsUser'
750: DESC 'User(s) impersonated by sudo'
751: EQUALITY caseExactIA5Match
752: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
753:
754: attributetype ( 1.3.6.1.4.1.15953.9.1.7
755: NAME 'sudoRunAsGroup'
756: DESC 'Group(s) impersonated by sudo'
757: EQUALITY caseExactIA5Match
758: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
759:
760: attributetype ( 1.3.6.1.4.1.15953.9.1.8
761: NAME 'sudoNotBefore'
762: DESC 'Start of time interval for which the entry is valid'
763: EQUALITY generalizedTimeMatch
764: ORDERING generalizedTimeOrderingMatch
765: SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
766:
767: attributetype ( 1.3.6.1.4.1.15953.9.1.9
768: NAME 'sudoNotAfter'
769: DESC 'End of time interval for which the entry is valid'
770: EQUALITY generalizedTimeMatch
771: ORDERING generalizedTimeOrderingMatch
772: SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
773:
774: attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
775: NAME 'sudoOrder'
776: DESC 'an integer to order the sudoRole entries'
777: EQUALITY integerMatch
778: ORDERING integerOrderingMatch
779: SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
780:
781: objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
782: DESC 'Sudoer Entries'
783: MUST ( cn )
784: MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
785: sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
786: sudoOrder $ description )
787: )
788:
789: SSEEEE AALLSSOO
790: ldap.conf(4), sudo.conf(4), sudoers(1m)
791:
792: CCAAVVEEAATTSS
793: Note that there are differences in the way that LDAP-based _s_u_d_o_e_r_s is
794: parsed compared to file-based _s_u_d_o_e_r_s. See the _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _L_D_A_P
795: _a_n_d _n_o_n_-_L_D_A_P _s_u_d_o_e_r_s section for more information.
796:
797: BBUUGGSS
798: If you feel you have found a bug in ssuuddoo, please submit a bug report at
799: http://www.sudo.ws/sudo/bugs/
800:
801: SSUUPPPPOORRTT
802: Limited free support is available via the sudo-users mailing list, see
803: http://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the
804: archives.
805:
806: DDIISSCCLLAAIIMMEERR
807: ssuuddoo is provided ``AS IS'' and any express or implied warranties,
808: including, but not limited to, the implied warranties of merchantability
809: and fitness for a particular purpose are disclaimed. See the LICENSE
810: file distributed with ssuuddoo or http://www.sudo.ws/sudo/license.html for
811: complete details.
812:
813: Sudo 1.8.8 August 30, 2013 Sudo 1.8.8
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to sudoers.ldap.cat CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / sudo / doc