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)). The default search filter
350: is: objectClass=sudoRole. If _l_d_a_p___f_i_l_t_e_r is omitted, no search
351: filter will be used.
352:
353: SSUUDDOOEERRSS__TTIIMMEEDD _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
354: Whether or not to evaluate the sudoNotBefore and sudoNotAfter
355: attributes that implement time-dependent sudoers entries.
356:
357: SSUUDDOOEERRSS__DDEEBBUUGG _d_e_b_u_g___l_e_v_e_l
358: This sets the debug level for ssuuddoo LDAP queries. Debugging
359: information is printed to the standard error. A value of 1 results
360: in a moderate amount of debugging information. A value of 2 shows
361: the results of the matches themselves. This parameter should not
362: be set in a production environment as the extra information is
363: likely to confuse users.
364:
365: The SSUUDDOOEERRSS__DDEEBBUUGG parameter is deprecated and will be removed in a
366: future release. The same information is now logged via the ssuuddoo
367: debugging framework using the ``ldap'' subsystem at priorities _d_i_a_g
368: and _i_n_f_o for _d_e_b_u_g___l_e_v_e_l values 1 and 2 respectively. See the
369: sudo.conf(4) manual for details on how to configure ssuuddoo debugging.
370:
371: BBIINNDDDDNN _D_N
372: The BBIINNDDDDNN parameter specifies the identity, in the form of a
373: Distinguished Name (DN), to use when performing LDAP operations.
374: If not specified, LDAP operations are performed with an anonymous
375: identity. By default, most LDAP servers will allow anonymous
376: access.
377:
378: BBIINNDDPPWW _s_e_c_r_e_t
379: The BBIINNDDPPWW parameter specifies the password to use when performing
380: LDAP operations. This is typically used in conjunction with the
381: BBIINNDDDDNN parameter.
382:
383: RROOOOTTBBIINNDDDDNN _D_N
384: The RROOOOTTBBIINNDDDDNN parameter specifies the identity, in the form of a
385: Distinguished Name (DN), to use when performing privileged LDAP
386: operations, such as _s_u_d_o_e_r_s queries. The password corresponding to
387: the identity should be stored in the or the path specified by the
388: _l_d_a_p___s_e_c_r_e_t plugin argument in sudo.conf(4), which defaults to
389: _/_e_t_c_/_l_d_a_p_._s_e_c_r_e_t. If no RROOOOTTBBIINNDDDDNN is specified, the BBIINNDDDDNN
390: identity is used (if any).
391:
392: LLDDAAPP__VVEERRSSIIOONN _n_u_m_b_e_r
393: The version of the LDAP protocol to use when connecting to the
394: server. The default value is protocol version 3.
395:
396: SSSSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
397: If the SSSSLL parameter is set to on, true or yes, TLS (SSL)
398: encryption is always used when communicating with the LDAP server.
399: Typically, this involves connecting to the server on port 636
400: (ldaps).
401:
402: SSSSLL _s_t_a_r_t___t_l_s
403: If the SSSSLL parameter is set to start_tls, the LDAP server
404: connection is initiated normally and TLS encryption is begun before
405: the bind credentials are sent. This has the advantage of not
406: requiring a dedicated port for encrypted communications. This
407: parameter is only supported by LDAP servers that honor the
408: _s_t_a_r_t___t_l_s extension, such as the OpenLDAP and Tivoli Directory
409: servers.
410:
411: TTLLSS__CCHHEECCKKPPEEEERR _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
412: If enabled, TTLLSS__CCHHEECCKKPPEEEERR will cause the LDAP server's TLS
413: certificated to be verified. If the server's TLS certificate
414: cannot be verified (usually because it is signed by an unknown
415: certificate authority), ssuuddoo will be unable to connect to it. If
416: TTLLSS__CCHHEECCKKPPEEEERR is disabled, no check is made. Note that disabling
417: the check creates an opportunity for man-in-the-middle attacks
418: since the server's identity will not be authenticated. If
419: possible, the CA's certificate should be installed locally so it
420: can be verified. This option is not supported by the Tivoli
421: Directory Server LDAP libraries.
422:
423: TTLLSS__CCAACCEERRTT _f_i_l_e _n_a_m_e
424: An alias for TTLLSS__CCAACCEERRTTFFIILLEE for OpenLDAP compatibility.
425:
426: TTLLSS__CCAACCEERRTTFFIILLEE _f_i_l_e _n_a_m_e
427: The path to a certificate authority bundle which contains the
428: certificates for all the Certificate Authorities the client knows
429: 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
430: supported by the OpenLDAP libraries. Netscape-derived LDAP
431: libraries use the same certificate database for CA and client
432: certificates (see TTLLSS__CCEERRTT).
433:
434: TTLLSS__CCAACCEERRTTDDIIRR _d_i_r_e_c_t_o_r_y
435: Similar to TTLLSS__CCAACCEERRTTFFIILLEE but instead of a file, it is a directory
436: containing individual Certificate Authority certificates, e.g.
437: _/_e_t_c_/_s_s_l_/_c_e_r_t_s. The directory specified by TTLLSS__CCAACCEERRTTDDIIRR is
438: checked after TTLLSS__CCAACCEERRTTFFIILLEE. This option is only supported by the
439: OpenLDAP libraries.
440:
441: TTLLSS__CCEERRTT _f_i_l_e _n_a_m_e
442: The path to a file containing the client certificate which can be
443: used to authenticate the client to the LDAP server. The
444: certificate type depends on the LDAP libraries used.
445:
446: OpenLDAP:
447: tls_cert /etc/ssl/client_cert.pem
448:
449: Netscape-derived:
450: tls_cert /var/ldap/cert7.db
451:
452: Tivoli Directory Server:
453: Unused, the key database specified by TTLLSS__KKEEYY contains both
454: keys and certificates.
455:
456: When using Netscape-derived libraries, this file may also
457: contain Certificate Authority certificates.
458:
459: TTLLSS__KKEEYY _f_i_l_e _n_a_m_e
460: The path to a file containing the private key which matches the
461: certificate specified by TTLLSS__CCEERRTT. The private key must not be
462: password-protected. The key type depends on the LDAP libraries
463: used.
464:
465: OpenLDAP:
466: tls_key /etc/ssl/client_key.pem
467:
468: Netscape-derived:
469: tls_key /var/ldap/key3.db
470:
471: Tivoli Directory Server:
472: tls_key /usr/ldap/ldapkey.kdb
473: When using Tivoli LDAP libraries, this file may also contain
474: Certificate Authority and client certificates and may be encrypted.
475:
476: TTLLSS__KKEEYYPPWW _s_e_c_r_e_t
477: The TTLLSS__KKEEYYPPWW contains the password used to decrypt the key
478: database on clients using the Tivoli Directory Server LDAP library.
479: This should be a simple string without quotes. The password may
480: not include the comment character (`#') and escaping of special
481: characters with a backslash (`\') is not supported. If this option
482: is used, _/_e_t_c_/_l_d_a_p_._c_o_n_f must not be world-readable to avoid
483: exposing the password. Alternately, a _s_t_a_s_h _f_i_l_e can be used to
484: store the password in encrypted form (see below).
485:
486: If no TTLLSS__KKEEYYPPWW is specified, a _s_t_a_s_h _f_i_l_e will be used if it
487: exists. The _s_t_a_s_h _f_i_l_e must have the same path as the file
488: specified by TTLLSS__KKEEYY, but use a .sth file extension instead of
489: .kdb, e.g. ldapkey.sth. The default ldapkey.kdb that ships with
490: Tivoli Directory Server is encrypted with the password
491: ssl_password. The _g_s_k_8_c_a_p_i_c_m_d utility can be used to manage the
492: key database and create a _s_t_a_s_h _f_i_l_e. This option is only
493: supported by the Tivoli LDAP libraries.
494:
495: TTLLSS__RRAANNDDFFIILLEE _f_i_l_e _n_a_m_e
496: The TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an entropy source
497: for systems that lack a random device. It is generally used in
498: conjunction with _p_r_n_g_d or _e_g_d. This option is only supported by
499: the OpenLDAP libraries.
500:
501: TTLLSS__CCIIPPHHEERRSS _c_i_p_h_e_r _l_i_s_t
502: The TTLLSS__CCIIPPHHEERRSS parameter allows the administer to restrict which
503: encryption algorithms may be used for TLS (SSL) connections. See
504: the OpenLDAP or Tivoli Directory Server manual for a list of valid
505: ciphers. This option is not supported by Netscape-derived
506: libraries.
507:
508: UUSSEE__SSAASSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
509: Enable UUSSEE__SSAASSLL for LDAP servers that support SASL authentication.
510:
511: SSAASSLL__AAUUTTHH__IIDD _i_d_e_n_t_i_t_y
512: The SASL user name to use when connecting to the LDAP server. By
513: default, ssuuddoo will use an anonymous connection.
514:
515: RROOOOTTUUSSEE__SSAASSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o
516: Enable RROOOOTTUUSSEE__SSAASSLL to enable SASL authentication when connecting
517: to an LDAP server from a privileged process, such as ssuuddoo.
518:
519: RROOOOTTSSAASSLL__AAUUTTHH__IIDD _i_d_e_n_t_i_t_y
520: The SASL user name to use when RROOOOTTUUSSEE__SSAASSLL is enabled.
521:
522: SSAASSLL__SSEECCPPRROOPPSS _n_o_n_e_/_p_r_o_p_e_r_t_i_e_s
523: SASL security properties or _n_o_n_e for no properties. See the SASL
524: programmer's manual for details.
525:
526: KKRRBB55__CCCCNNAAMMEE _f_i_l_e _n_a_m_e
527: The path to the Kerberos 5 credential cache to use when
528: authenticating with the remote server.
529:
530: 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
531: How alias dereferencing is to be performed when searching. See the
532: ldap.conf(1m) manual for a full description of this option.
533:
534: See the _l_d_a_p_._c_o_n_f entry in the _E_X_A_M_P_L_E_S section.
535:
536: CCoonnffiigguurriinngg nnsssswwiittcchh..ccoonnff
537: Unless it is disabled at build time, ssuuddoo consults the Name Service
538: 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.
539: Sudo looks for a line beginning with sudoers: and uses this to determine
540: the search order. Note that ssuuddoo does not stop searching after the first
541: match and later matches take precedence over earlier ones. The following
542: sources are recognized:
543:
544: files read sudoers from _/_e_t_c_/_s_u_d_o_e_r_s
545: ldap read sudoers from LDAP
546:
547: In addition, the entry [NOTFOUND=return] will short-circuit the search if
548: the user was not found in the preceding source.
549:
550: To consult LDAP first followed by the local sudoers file (if it exists),
551: use:
552:
553: sudoers: ldap files
554:
555: The local _s_u_d_o_e_r_s file can be ignored completely by using:
556:
557: sudoers: ldap
558:
559: 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
560: line, the following default is assumed:
561:
562: sudoers: files
563:
564: Note that _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f is supported even when the underlying
565: operating system does not use an nsswitch.conf file, except on AIX (see
566: below).
567:
568: CCoonnffiigguurriinngg nneettssvvcc..ccoonnff
569: On AIX systems, the _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f file is consulted instead of
570: _/_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
571: _n_s_s_w_i_t_c_h_._c_o_n_f; information in the previous section unrelated to the file
572: format itself still applies.
573:
574: To consult LDAP first followed by the local sudoers file (if it exists),
575: use:
576:
577: sudoers = ldap, files
578:
579: The local _s_u_d_o_e_r_s file can be ignored completely by using:
580:
581: sudoers = ldap
582:
583: To treat LDAP as authoritative and only use the local sudoers file if the
584: user is not present in LDAP, use:
585:
586: sudoers = ldap = auth, files
587:
588: Note that in the above example, the auth qualifier only affects user
589: lookups; both LDAP and _s_u_d_o_e_r_s will be queried for Defaults entries.
590:
591: 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,
592: the following default is assumed:
593:
594: sudoers = files
595:
596: FFIILLEESS
597: _/_e_t_c_/_l_d_a_p_._c_o_n_f LDAP configuration file
598:
599: _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f determines sudoers source order
600:
601: _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f determines sudoers source order on AIX
602:
603: EEXXAAMMPPLLEESS
604: EExxaammppllee llddaapp..ccoonnff
605: # Either specify one or more URIs or one or more host:port pairs.
606: # If neither is specified sudo will default to localhost, port 389.
607: #
608: #host ldapserver
609: #host ldapserver1 ldapserver2:390
610: #
611: # Default port if host is specified without one, defaults to 389.
612: #port 389
613: #
614: # URI will override the host and port settings.
615: uri ldap://ldapserver
616: #uri ldaps://secureldapserver
617: #uri ldaps://secureldapserver ldap://ldapserver
618: #
619: # The amount of time, in seconds, to wait while trying to connect to
620: # an LDAP server.
621: bind_timelimit 30
622: #
623: # The amount of time, in seconds, to wait while performing an LDAP query.
624: timelimit 30
625: #
626: # Must be set or sudo will ignore LDAP; may be specified multiple times.
627: sudoers_base ou=SUDOers,dc=example,dc=com
628: #
629: # verbose sudoers matching from ldap
630: #sudoers_debug 2
631: #
632: # Enable support for time-based entries in sudoers.
633: #sudoers_timed yes
634: #
635: # optional proxy credentials
636: #binddn <who to search as>
637: #bindpw <password>
638: #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
639: #
640: # LDAP protocol version, defaults to 3
641: #ldap_version 3
642: #
643: # Define if you want to use an encrypted LDAP connection.
644: # Typically, you must also set the port to 636 (ldaps).
645: #ssl on
646: #
647: # Define if you want to use port 389 and switch to
648: # encryption before the bind credentials are sent.
649: # Only supported by LDAP servers that support the start_tls
650: # extension such as OpenLDAP.
651: #ssl start_tls
652: #
653: # Additional TLS options follow that allow tweaking of the
654: # SSL/TLS connection.
655: #
656: #tls_checkpeer yes # verify server SSL certificate
657: #tls_checkpeer no # ignore server SSL certificate
658: #
659: # If you enable tls_checkpeer, specify either tls_cacertfile
660: # or tls_cacertdir. Only supported when using OpenLDAP.
661: #
662: #tls_cacertfile /etc/certs/trusted_signers.pem
663: #tls_cacertdir /etc/certs
664: #
665: # For systems that don't have /dev/random
666: # use this along with PRNGD or EGD.pl to seed the
667: # random number pool to generate cryptographic session keys.
668: # Only supported when using OpenLDAP.
669: #
670: #tls_randfile /etc/egd-pool
671: #
672: # You may restrict which ciphers are used. Consult your SSL
673: # documentation for which options go here.
674: # Only supported when using OpenLDAP.
675: #
676: #tls_ciphers <cipher-list>
677: #
678: # Sudo can provide a client certificate when communicating to
679: # the LDAP server.
680: # Tips:
681: # * Enable both lines at the same time.
682: # * Do not password protect the key file.
683: # * Ensure the keyfile is only readable by root.
684: #
685: # For OpenLDAP:
686: #tls_cert /etc/certs/client_cert.pem
687: #tls_key /etc/certs/client_key.pem
688: #
689: # For SunONE or iPlanet LDAP, tls_cert and tls_key may specify either
690: # a directory, in which case the files in the directory must have the
691: # default names (e.g. cert8.db and key4.db), or the path to the cert
692: # and key files themselves. However, a bug in version 5.0 of the LDAP
693: # SDK will prevent specific file names from working. For this reason
694: # it is suggested that tls_cert and tls_key be set to a directory,
695: # not a file name.
696: #
697: # The certificate database specified by tls_cert may contain CA certs
698: # and/or the client's cert. If the client's cert is included, tls_key
699: # should be specified as well.
700: # For backward compatibility, "sslpath" may be used in place of tls_cert.
701: #tls_cert /var/ldap
702: #tls_key /var/ldap
703: #
704: # If using SASL authentication for LDAP (OpenSSL)
705: # use_sasl yes
706: # sasl_auth_id <SASL user name>
707: # rootuse_sasl yes
708: # rootsasl_auth_id <SASL user name for root access>
709: # sasl_secprops none
710: # krb5_ccname /etc/.ldapcache
711:
712: SSuuddoo sscchheemmaa ffoorr OOppeennLLDDAAPP
713: The following schema, in OpenLDAP format, is included with ssuuddoo source
714: and binary distributions as _s_c_h_e_m_a_._O_p_e_n_L_D_A_P. Simply copy it to the
715: 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
716: in _s_l_a_p_d_._c_o_n_f and restart ssllaappdd.
717:
718: attributetype ( 1.3.6.1.4.1.15953.9.1.1
719: NAME 'sudoUser'
720: DESC 'User(s) who may run sudo'
721: EQUALITY caseExactIA5Match
722: SUBSTR caseExactIA5SubstringsMatch
723: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
724:
725: attributetype ( 1.3.6.1.4.1.15953.9.1.2
726: NAME 'sudoHost'
727: DESC 'Host(s) who may run sudo'
728: EQUALITY caseExactIA5Match
729: SUBSTR caseExactIA5SubstringsMatch
730: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
731:
732: attributetype ( 1.3.6.1.4.1.15953.9.1.3
733: NAME 'sudoCommand'
734: DESC 'Command(s) to be executed by sudo'
735: EQUALITY caseExactIA5Match
736: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
737:
738: attributetype ( 1.3.6.1.4.1.15953.9.1.4
739: NAME 'sudoRunAs'
740: DESC 'User(s) impersonated by sudo'
741: EQUALITY caseExactIA5Match
742: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
743:
744: attributetype ( 1.3.6.1.4.1.15953.9.1.5
745: NAME 'sudoOption'
746: DESC 'Options(s) followed by sudo'
747: EQUALITY caseExactIA5Match
748: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
749:
750: attributetype ( 1.3.6.1.4.1.15953.9.1.6
751: NAME 'sudoRunAsUser'
752: DESC 'User(s) impersonated by sudo'
753: EQUALITY caseExactIA5Match
754: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
755:
756: attributetype ( 1.3.6.1.4.1.15953.9.1.7
757: NAME 'sudoRunAsGroup'
758: DESC 'Group(s) impersonated by sudo'
759: EQUALITY caseExactIA5Match
760: SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
761:
762: attributetype ( 1.3.6.1.4.1.15953.9.1.8
763: NAME 'sudoNotBefore'
764: DESC 'Start of time interval for which the entry is valid'
765: EQUALITY generalizedTimeMatch
766: ORDERING generalizedTimeOrderingMatch
767: SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
768:
769: attributetype ( 1.3.6.1.4.1.15953.9.1.9
770: NAME 'sudoNotAfter'
771: DESC 'End of time interval for which the entry is valid'
772: EQUALITY generalizedTimeMatch
773: ORDERING generalizedTimeOrderingMatch
774: SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
775:
776: attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
777: NAME 'sudoOrder'
778: DESC 'an integer to order the sudoRole entries'
779: EQUALITY integerMatch
780: ORDERING integerOrderingMatch
781: SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
782:
783: objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
784: DESC 'Sudoer Entries'
785: MUST ( cn )
786: MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
787: sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
788: sudoOrder $ description )
789: )
790:
791: SSEEEE AALLSSOO
792: ldap.conf(4), sudo.conf(4), sudoers(1m)
793:
794: CCAAVVEEAATTSS
795: Note that there are differences in the way that LDAP-based _s_u_d_o_e_r_s is
796: 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
797: _a_n_d _n_o_n_-_L_D_A_P _s_u_d_o_e_r_s section for more information.
798:
799: BBUUGGSS
800: If you feel you have found a bug in ssuuddoo, please submit a bug report at
801: http://www.sudo.ws/sudo/bugs/
802:
803: SSUUPPPPOORRTT
804: Limited free support is available via the sudo-users mailing list, see
805: http://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the
806: archives.
807:
808: DDIISSCCLLAAIIMMEERR
809: ssuuddoo is provided ``AS IS'' and any express or implied warranties,
810: including, but not limited to, the implied warranties of merchantability
811: and fitness for a particular purpose are disclaimed. See the LICENSE
812: file distributed with ssuuddoo or http://www.sudo.ws/sudo/license.html for
813: complete details.
814:
815: Sudo 1.8.10 February 7, 2014 Sudo 1.8.10
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