1SUDOERS.LDAP(5) BSD File Formats Manual SUDOERS.LDAP(5)
2
4 sudoers.ldap — sudo LDAP configuration
5
7 In addition to the standard sudoers file, sudo may be configured via
8 LDAP. This can be especially useful for synchronizing sudoers in a
9 large, distributed environment.
10 Using LDAP for sudoers has several benefits:
12 • sudo no longer needs to read sudoers 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 environments.
16 • It is possible to specify per-entry options that override the global
18 default options. /etc/sudoers only supports default options and lim‐
19 ited options associated with user/host/commands/aliases. The syntax
20 is complicated and can be difficult for users to understand. Placing
21 the options directly in the entry is more natural.
22 • The visudo program is no longer needed. visudo provides locking and
24 syntax checking of the /etc/sudoers file. Since LDAP updates are
25 atomic, locking is no longer necessary. Because syntax is checked
26 when the data is inserted into LDAP, there is no need for a special‐
27 ized tool to check syntax.
28 SUDOers LDAP container
30 The sudoers configuration is contained in the ‘ou=SUDOers’ LDAP con‐
31 tainer.
32 Sudo first looks for the ‘cn=defaults’ entry in the SUDOers container.
34 If found, the multi-valued sudoOption attribute is parsed in the same
35 manner as a global Defaults line in /etc/sudoers. In the following exam‐
36 ple, the SSH_AUTH_SOCK variable will be preserved in the environment for
37 all users.
38 dn: cn=defaults,ou=SUDOers,dc=my-domain,dc=com
40 objectClass: top
41 objectClass: sudoRole
42 cn: defaults
43 description: Default sudoOption's go here
44 sudoOption: env_keep+=SSH_AUTH_SOCK
45 The equivalent of a sudoer in LDAP is a sudoRole. It consists of the
47 following attributes:
48 sudoUser
50 A user name, user-ID (prefixed with ‘#’), Unix group name or ID
51 (prefixed with ‘%’ or ‘%#’ respectively), user netgroup (prefixed
52 with ‘+’), or non-Unix group name or ID (prefixed with ‘%:’ or
53 ‘%:#’ respectively). User netgroups are matched using the user and
54 domain members only; the host member is not used when matching.
55 Non-Unix group support is only available when an appropriate
56 group_plugin is defined in the global defaults sudoRole object. If
57 a sudoUser entry is preceded by an exclamation point, ‘!’, and the
58 entry matches, the sudoRole in which it resides will be ignored.
59 Negated sudoUser entries are only supported by version 1.9.9 or
60 higher.
61 sudoHost
63 A host name, IP address, IP network, or host netgroup (prefixed
64 with a ‘+’). The special value ALL will match any host. Host net‐
65 groups are matched using the host (both qualified and unqualified)
66 and domain members only; the user member is not used when matching.
67 If a sudoHost entry is preceded by an exclamation point, ‘!’, and
68 the entry matches, the sudoRole in which it resides will be ig‐
69 nored. Negated sudoHost entries are only supported by version
70 1.8.18 or higher.
71 sudoCommand
73 A fully-qualified Unix command name with optional command line ar‐
74 guments, potentially including globbing characters (aka wild
75 cards). If a command name is preceded by an exclamation point,
76 ‘!’, the user will be prohibited from running that command.
77 The built-in command “sudoedit” is used to permit a user to run
79 sudo with the -e option (or as sudoedit). It may take command line
80 arguments just as a normal command does. Unlike other commands,
81 “sudoedit” is a built into sudo itself and must be specified in
82 without a leading path.
83 The special value ALL will match any command.
85 If a command name is prefixed with a SHA-2 digest, it will only be
87 allowed if the digest matches. This may be useful in situations
88 where the user invoking sudo has write access to the command or its
89 parent directory. The following digest formats are supported:
90 sha224, sha256, sha384, and sha512. The digest name must be fol‐
91 lowed by a colon (‘:’) and then the actual digest, in either hex or
92 base64 format. For example, given the following value for sudoCom‐
93 mand:
94 sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
96 The user may only run /bin/ls if its sha224 digest matches the
98 specified value. Command digests are only supported by version
99 1.8.7 or higher.
100 sudoOption
102 Identical in function to the global options described above, but
103 specific to the sudoRole in which it resides.
104 sudoRunAsUser
106 A user name or user-ID (prefixed with ‘#’) that commands may be run
107 as or a Unix group (prefixed with a ‘%’) or user netgroup (prefixed
108 with a ‘+’) that contains a list of users that commands may be run
109 as. The special value ALL will match any user. If a sudoRunAsUser
110 entry is preceded by an exclamation point, ‘!’, and the entry
111 matches, the sudoRole in which it resides will be ignored. If
112 sudoRunAsUser is specified but empty, it will match the invoking
113 user. If neither sudoRunAsUser nor sudoRunAsGroup are present, the
114 value of the runas_default sudoOption is used (defaults to root).
115 The sudoRunAsUser attribute is only available in sudo versions
117 1.7.0 and higher. Older versions of sudo use the sudoRunAs attri‐
118 bute instead. Negated sudoRunAsUser entries are only supported by
119 version 1.8.26 or higher.
120 sudoRunAsGroup
122 A Unix group or group-ID (prefixed with ‘#’) that commands may be
123 run as. The special value ALL will match any group. If a
124 sudoRunAsGroup entry is preceded by an exclamation point, ‘!’, and
125 the entry matches, the sudoRole in which it resides will be ig‐
126 nored.
127 The sudoRunAsGroup attribute is only available in sudo versions
129 1.7.0 and higher. Negated sudoRunAsGroup entries are only sup‐
130 ported by version 1.8.26 or higher.
131 sudoNotBefore
133 A timestamp in the form ‘yyyymmddHHMMSSZ’ that can be used to pro‐
134 vide a start date/time for when the sudoRole will be valid. If
135 multiple sudoNotBefore entries are present, the earliest is used.
136 Timestamps must be in Coordinated Universal Time (UTC), not the lo‐
137 cal timezone. The minute and seconds portions are optional, but
138 some LDAP servers require that they be present (contrary to the
139 RFC).
140 The sudoNotBefore attribute is only available in sudo versions
142 1.7.5 and higher and must be explicitly enabled via the
143 SUDOERS_TIMED option in /etc/ldap.conf.
144 sudoNotAfter
146 A timestamp in the form ‘yyyymmddHHMMSSZ’ that indicates an expira‐
147 tion date/time, after which the sudoRole will no longer be valid.
148 If multiple sudoNotAfter entries are present, the last one is used.
149 Timestamps must be in Coordinated Universal Time (UTC), not the lo‐
150 cal timezone. The minute and seconds portions are optional, but
151 some LDAP servers require that they be present (contrary to the
152 RFC).
153 The sudoNotAfter attribute is only available in sudo versions 1.7.5
155 and higher and must be explicitly enabled via the SUDOERS_TIMED op‐
156 tion in /etc/ldap.conf.
157 sudoOrder
159 The sudoRole entries retrieved from the LDAP directory have no in‐
160 herent order. The sudoOrder attribute is an integer (or floating
161 point value for LDAP servers that support it) that is used to sort
162 the matching entries. This allows LDAP-based sudoers entries to
163 more closely mimic the behavior of the sudoers file, where the or‐
164 der of the entries influences the result. If multiple entries
165 match, the entry with the highest sudoOrder attribute is chosen.
166 This corresponds to the “last match” behavior of the sudoers file.
167 If the sudoOrder attribute is not present, a value of 0 is assumed.
168 The sudoOrder attribute is only available in sudo versions 1.7.5
170 and higher.
171 Each attribute listed above should contain a single value, but there may
173 be multiple instances of each attribute type. A sudoRole must contain at
174 least one sudoUser, sudoHost, and sudoCommand.
175 The following example allows users in group wheel to run any command on
177 any host via sudo:
178 dn: cn=%wheel,ou=SUDOers,dc=my-domain,dc=com
180 objectClass: top
181 objectClass: sudoRole
182 cn: %wheel
183 sudoUser: %wheel
184 sudoHost: ALL
185 sudoCommand: ALL
186 Anatomy of LDAP sudoers lookup
188 When looking up a sudoer using LDAP there are only two or three LDAP
189 queries per invocation. The first query is to parse the global options.
190 The second is to match against the user's name and the groups that the
191 user belongs to. (The special ALL tag is matched in this query too.) If
192 no match is returned for the user's name and groups, a third query re‐
193 turns all entries containing user netgroups and other non-Unix groups and
194 checks to see if the user belongs to any of them.
195 If timed entries are enabled with the SUDOERS_TIMED parameter, the LDAP
197 queries include a sub-filter that limits retrieval to entries that sat‐
198 isfy the time constraints, if any.
199 If the NETGROUP_BASE parameter is present and NETGROUP_QUERY has not been
201 disabled (see Configuring ldap.conf below), queries are performed to de‐
202 termine the list of netgroups the user belongs to before the sudoers
203 query. This makes it possible to include netgroups in the sudoers query
204 string in the same manner as Unix groups. The third query mentioned
205 above is not performed unless a group provider plugin is also configured.
206 The actual LDAP queries performed by sudo are as follows:
207 1. Match all nisNetgroup records with a nisNetgroupTriple containing
209 the user, host, and NIS domain. The query will match
210 nisNetgroupTriple entries with either the short or long form of the
211 host name or no host name specified in the tuple. If the NIS domain
212 is set, the query will match only match entries that include the do‐
213 main or for which there is no domain present. If the NIS domain is
214 not set, a wildcard is used to match any domain name but be aware
215 that the NIS schema used by some LDAP servers may not support wild
216 cards for nisNetgroupTriple.
217 2. Repeated queries are performed to find any nested nisNetgroup
219 records with a memberNisNetgroup entry that refers to an already-
220 matched record.
221 For sites with a large number of netgroups, using NETGROUP_BASE can sig‐
223 nificantly speed up sudo's execution time as long as the LDAP server sup‐
224 ports querying the nisNetgroup object by its nisNetgroupTriple attribute.
225 Differences between LDAP and non-LDAP sudoers
227 One of the major differences between LDAP and file-based sudoers is that
228 in LDAP, sudo-specific Aliases are not supported.
229 For the most part, there is little need for sudo-specific Aliases. Unix
231 groups, non-Unix groups (via the group_plugin), or user netgroups can be
232 used in place of User_Aliases and Runas_Aliases. Host netgroups can be
233 used in place of Host_Aliases. Since groups and netgroups can also be
234 stored in LDAP there is no real need for sudo-specific aliases.
235 There are also some subtle differences in the way sudoers is handled once
237 in LDAP. Probably the biggest is that according to the RFC, LDAP order‐
238 ing is arbitrary and you cannot expect that Attributes and Entries are
239 returned in any specific order.
240 The order in which different entries are applied can be controlled using
242 the sudoOrder attribute, but there is no way to guarantee the order of
243 attributes within a specific entry. If there are conflicting command
244 rules in an entry, the negative takes precedence. This is called para‐
245 noid behavior (not necessarily the most specific match).
246 Here is an example:
248 # /etc/sudoers:
250 # Allow all commands except shell
251 johnny ALL=(root) ALL,!/bin/sh
252 # Always allows all commands because ALL is matched last
253 puddles ALL=(root) !/bin/sh,ALL
254 # LDAP equivalent of johnny
256 # Allows all commands except shell
257 dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
258 objectClass: sudoRole
259 objectClass: top
260 cn: role1
261 sudoUser: johnny
262 sudoHost: ALL
263 sudoCommand: ALL
264 sudoCommand: !/bin/sh
265 # LDAP equivalent of puddles
267 # Notice that even though ALL comes last, it still behaves like
268 # role1 since the LDAP code assumes the more paranoid configuration
269 dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
270 objectClass: sudoRole
271 objectClass: top
272 cn: role2
273 sudoUser: puddles
274 sudoHost: ALL
275 sudoCommand: !/bin/sh
276 sudoCommand: ALL
277 Converting between file-based and LDAP sudoers
279 The cvtsudoers(1) utility can be used to convert between file-based and
280 LDAP sudoers. However, there are features in the file-based sudoers that
281 have no equivalent in LDAP-based sudoers (and vice versa). These cannot
282 be converted automatically.
283 For example, a Cmnd_Alias in a sudoers file may be converted to a
285 sudoRole that contains multiple commands. Multiple users and/or groups
286 may be assigned to the sudoRole.
287 Also, host, user, runas, and command-based Defaults entries are not sup‐
289 ported. However, a sudoRole may contain one or more sudoOption at‐
290 tributes which can often serve the same purpose.
291 Consider the following sudoers lines:
293 Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less
295 Defaults!PAGERS noexec
296 alice, bob ALL = ALL
297 In this example, alice and bob are allowed to run all commands, but the
299 commands listed in PAGERS will have the noexec flag set, preventing shell
300 escapes.
301 When converting this to LDAP, two sudoRole objects can be used:
303 dn: cn=PAGERS,ou=SUDOers,dc=my-domain,dc=com
305 objectClass: top
306 objectClass: sudoRole
307 cn: PAGERS
308 sudoUser: alice
309 sudoUser: bob
310 sudoHost: ALL
311 sudoCommand: /usr/bin/more
312 sudoCommand: /usr/bin/pg
313 sudoCommand: /usr/bin/less
314 sudoOption: noexec
315 sudoOrder: 900
316 dn: cn=ADMINS,ou=SUDOers,dc=my-domain,dc=com
318 objectClass: top
319 objectClass: sudoRole
320 cn: ADMINS
321 sudoUser: alice
322 sudoUser: bob
323 sudoHost: ALL
324 sudoCommand: ALL
325 sudoOrder: 100
326 In the LDAP version, the sudoOrder attribute is used to guarantee that
328 the PAGERS sudoRole with noexec has precedence. Unlike the sudoers ver‐
329 sion, the LDAP version requires that all users for whom the restriction
330 should apply be assigned to the PAGERS sudoRole. Using a Unix group or
331 netgroup in PAGERS rather than listing each user would make this easier
332 to maintain.
333 Per-user Defaults entries can be emulated by using one or more sudoOption
335 attributes in a sudoRole. Consider the following sudoers lines:
336 User_Alias ADMINS = john, sally
338 Defaults:ADMINS !authenticate
339 ADMINS ALL = (ALL:ALL) ALL
340 In this example, john and sally are allowed to run any command as any
342 user or group.
343 When converting this to LDAP, we can use a Unix group instead of the
345 User_Alias.
346 dn: cn=admins,ou=SUDOers,dc=my-domain,dc=com
348 objectClass: top
349 objectClass: sudoRole
350 cn: admins
351 sudoUser: %admin
352 sudoHost: ALL
353 sudoRunAsUser: ALL
354 sudoRunAsGroup: ALL
355 sudoCommand: ALL
356 sudoOption: !authenticate
357 This assumes that users john and sally are members of the “admins” Unix
359 group.
360 Sudoers schema
362 In order to use sudo's LDAP support, the sudo schema must be installed on
363 your LDAP server. In addition, be sure to index the sudoUser attribute.
364 The sudo distribution includes versions of the sudoers schema for multi‐
366 ple LDAP servers:
367 schema.OpenLDAP
369 OpenLDAP slapd and OpenBSD ldapd
370 schema.olcSudo
372 OpenLDAP slapd 2.3 and higher when on-line configuration is enabled
373 schema.iPlanet
375 Netscape-derived servers such as the iPlanet, Oracle, and 389 Di‐
376 rectory Servers
377 schema.ActiveDirectory
379 Microsoft Active Directory
380 The schema in OpenLDAP format is also included in the EXAMPLES section.
382 Configuring ldap.conf
384 Sudo reads the /etc/ldap.conf file for LDAP-specific configuration. Typ‐
385 ically, this file is shared between different LDAP-aware clients. As
386 such, most of the settings are not sudo-specific. The /etc/ldap.conf file
387 is parsed by sudo itself and may support options that differ from those
388 described in the system's ldap.conf(5) manual. The path to ldap.conf may
389 be overridden via the ldap_conf plugin argument in sudo.conf(5).
390 On systems using the OpenLDAP libraries, default values specified in
392 /etc/openldap/ldap.conf or the user's .ldaprc files are not used.
393 sudo supports a variety of LDAP library implementations, including OpenL‐
395 DAP, Netscape-derived (also used by Solaris and HP-UX), and IBM LDAP (aka
396 Tivoli). Some options are specific to certain LDAP implementations or
397 have implementation-specific behavior. These differences are noted below
398 where applicable.
399 Only those options explicitly listed in /etc/ldap.conf as being supported
401 by sudo are honored. Configuration options are listed below in upper
402 case but are parsed in a case-independent manner.
403 Lines beginning with a pound sign (‘#’) are ignored. Leading white space
405 is removed from the beginning of lines.
406 BIND_TIMELIMIT seconds
408 The BIND_TIMELIMIT parameter specifies the amount of time, in sec‐
409 onds, to wait while trying to connect to an LDAP server. If multi‐
410 ple URIs or HOSTs are specified, this is the amount of time to wait
411 before trying the next one in the list.
412 BINDDN DN
414 The BINDDN parameter specifies the identity, in the form of a Dis‐
415 tinguished Name (DN), to use when performing LDAP operations. If
416 not specified, LDAP operations are performed with an anonymous
417 identity. By default, most LDAP servers will allow anonymous ac‐
418 cess.
419 BINDPW secret
421 The BINDPW parameter specifies the password to use when performing
422 LDAP operations. This is typically used in conjunction with the
423 BINDDN parameter. The secret may be a plaintext password or a
424 base64-encoded string with a “base64:” prefix. For example:
425 BINDPW base64:dGVzdA==
427 If a plaintext password is used, it should be a simple string with‐
429 out quotes. Plain text passwords may not include the comment char‐
430 acter (‘#’) and the escaping of special characters with a backslash
431 (‘\’) is not supported.
432 DEREF never/searching/finding/always
434 How alias dereferencing is to be performed when searching. See the
435 ldap.conf(5) manual for a full description of this option.
436 HOST name[:port] ...
438 If no URI is specified (see below), the HOST parameter specifies a
439 white space-delimited list of LDAP servers to connect to. Each
440 host may include an optional port separated by a colon (‘:’). The
441 HOST parameter is deprecated in favor of the URI specification and
442 is included for backward compatibility only.
443 KRB5_CCNAME file name
445 The path to the Kerberos 5 credential cache to use when authenti‐
446 cating with the remote server.
447 This option is only relevant when using SASL authentication (see
449 below).
450 LDAP_VERSION number
452 The version of the LDAP protocol to use when connecting to the
453 server. The default value is protocol version 3.
454 NETGROUP_BASE base
456 The base DN to use when performing LDAP netgroup queries. Typi‐
457 cally this is of the form ‘ou=netgroup,dc=my-domain,dc=com’ for the
458 domain my-domain.com. Multiple NETGROUP_BASE lines may be speci‐
459 fied, in which case they are queried in the order specified.
460 When this option is enabled, sudo will query the LDAP server di‐
462 rectly when matching netgroups present in a sudoRole instead of re‐
463 lying on the C library's innetgr() function.
464 Additionally, if the NETGROUP_QUERY parameter (which is enabled by
466 default) has not been disabled, the user's netgroups will be
467 queried directly via LDAP for use in the main sudoers query. This
468 is usually faster than fetching every sudoRole object containing a
469 sudoUser that begins with a ‘+’ prefix and checking whether the
470 user is a member of each one. The NIS schema used by some LDAP
471 servers needs a modification to support querying the nisNetgroup
472 object by its nisNetgroupTriple attribute. For example, OpenLDAP's
473 slapd requires the following change to the nisNetgroupTriple attri‐
474 bute:
475 attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
477 DESC 'Netgroup triple'
478 EQUALITY caseIgnoreIA5Match
479 SUBSTR caseIgnoreIA5SubstringsMatch
480 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
481 Before enabling NETGROUP_BASE, you should verify that your LDAP
483 server supports matching nisNetgroupTriple. For example, using
484 ldapsearch:
485 $ ldapsearch -b $NETGROUP_BASE \
487 '(&(objectClass=nisNetgroup)(nisNetgroupTriple=\28*,USER,\29))'
488 where your nisNetgroup data includes an object with the following
490 nisNetgroupTriple:
491 nisNetgroupTriple: (,USER,)
493 NETGROUP_QUERY on/true/yes/off/false/no
495 The NETGROUP_QUERY parameter indicates whether or not the LDAP
496 server supports querying nisNetgroup objects by matching on
497 nisNetgroupTriple attributes. By default, sudoers expects to be
498 able to perform queries that match on nisNetgroupTriple attributes
499 when NETGROUP_BASE is set, but not all LDAP servers support this.
500 If NETGROUP_QUERY is disabled, sudoers will not attempt to deter‐
502 mine the list of netgroups the user belongs to, but will still use
503 NETGROUP_BASE directly when matching netgroups. This can be used
504 to support netgroups on systems that lack the innetgr() C library
505 function. See the description of the NETGROUP_BASE parameter for
506 more information.
507 NETGROUP_SEARCH_FILTER ldap_filter
509 An LDAP filter which is used to restrict the set of records re‐
510 turned when performing an LDAP netgroup query. Typically, this is
511 of the form ‘attribute=value’ or
512 ‘(&(attribute=value)(attribute2=value2))’. The default search fil‐
513 ter is: ‘objectClass=nisNetgroup’. If ldap_filter is omitted, no
514 search filter will be used.
515 This option is only used when querying netgroups directly via LDAP.
517 NETWORK_TIMEOUT seconds
519 An alias for BIND_TIMELIMIT provided for OpenLDAP compatibility.
520 PORT port_number
522 If no URI is specified, the PORT parameter specifies the default
523 port to connect to on the LDAP server if a HOST parameter does not
524 specify the port itself. If no PORT parameter is used, the default
525 is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
526 PORT parameter is deprecated in favor of the URI specification and
527 is included for backward compatibility only.
528 ROOTBINDDN DN
530 The ROOTBINDDN parameter specifies the identity, in the form of a
531 Distinguished Name (DN), to use when performing privileged LDAP op‐
532 erations, such as sudoers queries. The password corresponding to
533 the identity should be stored in the or the path specified by the
534 ldap_secret plugin argument in sudo.conf(5), which defaults to
535 /etc/ldap.secret. If no ROOTBINDDN is specified, the BINDDN iden‐
536 tity is used (if any).
537 ROOTUSE_SASL on/true/yes/off/false/no
539 Enable ROOTUSE_SASL to enable SASL authentication when connecting
540 to an LDAP server from a privileged process, such as sudo.
541 SASL_AUTH_ID identity
543 The SASL user name to use when connecting to the LDAP server. By
544 default, sudo will use an anonymous connection.
545 This option is only relevant when using SASL authentication.
547 SASL_MECH mechanisms
549 A white space-delimited list of SASL authentication mechanisms to
550 use. By default, sudo will use GSSAPI authentication.
551 SASL_SECPROPS none/properties
553 SASL security properties or none for no properties. See the SASL
554 programmer's manual for details.
555 This option is only relevant when using SASL authentication.
557 SSL on/true/yes/off/false/no
559 If the SSL parameter is set to on, true, or yes TLS (SSL) encryp‐
560 tion is always used when communicating with the LDAP server. Typi‐
561 cally, this involves connecting to the server on port 636 (ldaps).
562 SSL start_tls
564 If the SSL parameter is set to start_tls, the LDAP server connec‐
565 tion is initiated normally and TLS encryption is begun before the
566 bind credentials are sent. This has the advantage of not requiring
567 a dedicated port for encrypted communications. This parameter is
568 only supported by LDAP servers that honor the start_tls extension,
569 such as the OpenLDAP and IBM Tivoli Directory servers.
570 SUDOERS_BASE base
572 The base DN to use when performing sudo LDAP queries. Typically
573 this is of the form ‘ou=SUDOers,dc=my-domain,dc=com’ for the domain
574 my-domain.com. Multiple SUDOERS_BASE lines may be specified, in
575 which case they are queried in the order specified.
576 SUDOERS_DEBUG debug_level
578 This sets the debug level for sudo LDAP queries. Debugging infor‐
579 mation is printed to the standard error. A value of 1 results in a
580 moderate amount of debugging information. A value of 2 shows the
581 results of the matches themselves. This parameter should not be
582 set in a production environment as the extra information is likely
583 to confuse users.
584 The SUDOERS_DEBUG parameter is deprecated and will be removed in a
586 future release. The same information is now logged via the sudo
587 debugging framework using the “ldap” subsystem at priorities diag
588 and info for debug_level values 1 and 2 respectively. See the
589 sudo.conf(5) manual for details on how to configure sudo debugging.
590 SUDOERS_SEARCH_FILTER ldap_filter
592 An LDAP filter which is used to restrict the set of records re‐
593 turned when performing a sudo LDAP query. Typically, this is of
594 the form ‘attribute=value’ or
595 ‘(&(attribute=value)(attribute2=value2))’. The default search fil‐
596 ter is: ‘objectClass=sudoRole’. If ldap_filter is omitted, no
597 search filter will be used.
598 SUDOERS_TIMED on/true/yes/off/false/no
600 Whether or not to evaluate the sudoNotBefore and sudoNotAfter at‐
601 tributes that implement time-dependent sudoers entries.
602 TIMELIMIT seconds
604 The TIMELIMIT parameter specifies the amount of time, in seconds,
605 to wait for a response to an LDAP query.
606 TIMEOUT seconds
608 The TIMEOUT parameter specifies the amount of time, in seconds, to
609 wait for a response from the various LDAP APIs.
610 TLS_CACERT file name
612 An alias for TLS_CACERTFILE for OpenLDAP compatibility.
613 TLS_CACERTFILE file name
615 The path to a certificate authority bundle which contains the cer‐
616 tificates for all the Certificate Authorities the client knows to
617 be valid, e.g., /etc/ssl/ca-bundle.pem.
618 This option is only supported by the OpenLDAP libraries. Netscape-
620 derived LDAP libraries use the same certificate database for CA and
621 client certificates (see TLS_CERT).
622 TLS_CACERTDIR directory
624 Similar to TLS_CACERTFILE but instead of a file, it is a directory
625 containing individual Certificate Authority certificates, e.g.,
626 /etc/ssl/certs. The directory specified by TLS_CACERTDIR is
627 checked after TLS_CACERTFILE.
628 This option is only supported by the OpenLDAP libraries.
630 TLS_CERT file name
632 The path to a file containing the client certificate which can be
633 used to authenticate the client to the LDAP server. The certifi‐
634 cate type depends on the LDAP libraries used.
635 OpenLDAP:
637 ‘tls_cert /etc/ssl/client_cert.pem’
638 Netscape-derived:
640 ‘tls_cert /var/ldap/cert7.db’
641 IBM LDAP:
643 Unused, the key database specified by TLS_KEY contains both
644 keys and certificates.
645 When using Netscape-derived libraries, this file may also contain
647 Certificate Authority certificates.
648 TLS_CHECKPEER on/true/yes/off/false/no
650 If enabled, TLS_CHECKPEER will cause the LDAP server's TLS certifi‐
651 cated to be verified. If the server's TLS certificate cannot be
652 verified (usually because it is signed by an unknown certificate
653 authority), sudo will be unable to connect to it. If TLS_CHECKPEER
654 is disabled, no check is made. Disabling this check creates an op‐
655 portunity for man-in-the-middle attacks since the server's identity
656 will not be authenticated. If possible, the CA's certificate
657 should be installed locally so it can be verified.
658 This option is not supported by the IBM LDAP libraries.
660 TLS_KEY file name
662 The path to a file containing the private key which matches the
663 certificate specified by TLS_CERT. The private key must not be
664 password-protected. The key type depends on the LDAP libraries
665 used.
666 OpenLDAP:
668 ‘tls_key /etc/ssl/client_key.pem’
669 Netscape-derived:
671 ‘tls_key /var/ldap/key3.db’
672 IBM LDAP:
674 ‘tls_key /usr/ldap/ldapkey.kdb’
675 When using IBM LDAP libraries, this file may also contain Certifi‐
677 cate Authority and client certificates and may be encrypted.
678 TLS_CIPHERS cipher list
680 The TLS_CIPHERS parameter allows the administer to restrict which
681 encryption algorithms may be used for TLS (SSL) connections. See
682 the OpenLDAP or IBM Tivoli Directory Server manual for a list of
683 valid ciphers.
684 This option is not supported by Netscape-derived libraries.
686 TLS_KEYPW secret
688 The TLS_KEYPW contains the password used to decrypt the key data‐
689 base on clients using the IBM LDAP library. The secret may be a
690 plaintext password or a base64-encoded string with a “base64:” pre‐
691 fix. For example:
692 TLS_KEYPW base64:dGVzdA==
694 If a plaintext password is used, it should be a simple string with‐
696 out quotes. Plain text passwords may not include the comment char‐
697 acter (‘#’) and the escaping of special characters with a backslash
698 (‘\’) is not supported. If this option is used, /etc/ldap.conf
699 must not be world-readable to avoid exposing the password. Alter‐
700 nately, a stash file can be used to store the password in encrypted
701 form (see below).
702 If no TLS_KEYPW is specified, a stash file will be used if it ex‐
704 ists. The stash file must have the same path as the file specified
705 by TLS_KEY, but use a ‘.sth’ file extension instead of ‘.kdb’, for
706 example ‘ldapkey.sth’. The default ‘ldapkey.kdb’ that ships with
707 the IBM Tivoli Directory Server is encrypted with the password
708 ‘ssl_password’. The gsk8capicmd utility can be used to manage the
709 key database and create a stash file.
710 This option is only supported by the IBM LDAP libraries.
712 TLS_REQCERT level
714 The TLS_REQCERT parameter controls how the LDAP server's TLS cer‐
715 tificated will be verified (if at all). If the server's TLS cer‐
716 tificate cannot be verified (usually because it is signed by an un‐
717 known certificate authority), sudo will be unable to connect to it.
718 The following level values are supported:
719 never
721 The server certificate will not be requested or checked.
722 allow
724 The server certificate will be requested. A missing or
725 invalid certificate is ignored and not considered an er‐
726 ror.
727 try The server certificate will be requested. A missing cer‐
729 tificate is ignored but an invalid certificate will re‐
730 sult in a connection error.
731 demand | hard
733 The server certificate will be requested. A missing or
734 invalid certificate will result in a connection error.
735 This is the default behavior.
736 This option is only supported by the OpenLDAP libraries. Other
738 LDAP libraries only support the TLS_CHECKPEER parameter.
739 TLS_RANDFILE file name
741 The TLS_RANDFILE parameter specifies the path to an entropy source
742 for systems that lack a random device. It is generally used in
743 conjunction with prngd or egd.
744 This option is only supported by the OpenLDAP libraries.
746 URI ldap[s]://[hostname[:port]] ...
748 Specifies a white space-delimited list of one or more URIs describ‐
749 ing the LDAP server(s) to connect to. The protocol may be either
750 ldap ldaps, the latter being for servers that support TLS (SSL) en‐
751 cryption. If no port is specified, the default is port 389 for
752 ‘ldap://’ or port 636 for ‘ldaps://’. If no hostname is specified,
753 sudo will connect to localhost. Multiple URI lines are treated
754 identically to a URI line containing multiple entries. Only sys‐
755 tems using the OpenSSL libraries support the mixing of ‘ldap://’
756 and ‘ldaps://’ URIs. Both the Netscape-derived and IBM LDAP li‐
757 braries used on most commercial versions of Unix are only capable
758 of supporting one or the other.
759 USE_SASL on/true/yes/off/false/no
761 Enable USE_SASL for LDAP servers that support SASL authentication.
762 ROOTSASL_AUTH_ID identity
764 The SASL user name to use when ROOTUSE_SASL is enabled.
765 See the ldap.conf entry in the EXAMPLES section.
767 Configuring nsswitch.conf
769 Unless it is disabled at build time, sudo consults the Name Service
770 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
771 Sudo looks for a line beginning with sudoers: and uses this to determine
772 the search order. By default, sudo does not stop searching after the
773 first match and later matches take precedence over earlier ones (unless
774 ‘[SUCCESS=return]’ is used, see below). The following sources are recog‐
775 nized:
776 files read sudoers from /etc/sudoers
778 ldap read sudoers from LDAP
779 In addition, a subset of nsswitch.conf-style action statements is sup‐
781 ported, specifically ‘[SUCCESS=return]’ and ‘[NOTFOUND=return]’. These
782 will unconditionally terminate the search if the user was either found
783 ‘[SUCCESS=return]’ or not found ‘[NOTFOUND=return]’ in the immediately
784 preceding source. Other action statements tokens are not supported, nor
785 is test negation with ‘!’.
786 To consult LDAP first followed by the local sudoers file (if it exists),
788 use:
789 sudoers: ldap files
791 To consult LDAP only when no match is found in the local sudoers file (if
793 it exists), use:
794 sudoers: files [SUCCESS=return] ldap
796 The local sudoers file can be ignored completely by using:
798 sudoers: ldap
800 If the /etc/nsswitch.conf file is not present or there is no sudoers
802 line, the following default is assumed:
803 sudoers: files
805 The /etc/nsswitch.conf file is supported even when the underlying operat‐
807 ing system does not support it, except on AIX (see below).
808 Configuring netsvc.conf
810 On AIX systems, the /etc/netsvc.conf file is consulted instead of
811 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
812 nsswitch.conf; information in the previous section unrelated to the file
813 format itself still applies.
814 To consult LDAP first followed by the local sudoers file (if it exists),
816 use:
817 sudoers = ldap, files
819 The local sudoers file can be ignored completely by using:
821 sudoers = ldap
823 To treat LDAP as authoritative and only use the local sudoers file if the
825 user is not present in LDAP, use:
826 sudoers = ldap = auth, files
828 In the above example, the auth qualifier only affects user lookups; both
830 LDAP and sudoers will be queried for Defaults entries.
831 If the /etc/netsvc.conf file is not present or there is no sudoers line,
833 the following default is assumed:
834 sudoers = files
836 Integration with sssd
838 On systems with the System Security Services Daemon (SSSD) and where sudo
839 has been built with SSSD support, it is possible to use SSSD to cache
840 LDAP sudoers rules. To use SSSD as the sudoers source, you should use
841 sss instead of ldap for the sudoers entry in /etc/nsswitch.conf. The
842 /etc/ldap.conf file is not used by the SSSD sudo back end. See
843 sssd-sudo(5) for more information on configuring sudo to work with SSSD.
844
846 /etc/ldap.conf LDAP configuration file
847 /etc/nsswitch.conf determines sudoers source order
849 /etc/netsvc.conf determines sudoers source order on AIX
851
853 Example ldap.conf
854 # Either specify one or more URIs or one or more host:port pairs.
855 # If neither is specified sudo will default to localhost, port 389.
856 #
857 #host ldapserver
858 #host ldapserver1 ldapserver2:390
859 #
860 # Default port if host is specified without one, defaults to 389.
861 #port 389
862 #
863 # URI will override the host and port settings.
864 uri ldap://ldapserver
865 #uri ldaps://secureldapserver
866 #uri ldaps://secureldapserver ldap://ldapserver
867 #
868 # The amount of time, in seconds, to wait while trying to connect to
869 # an LDAP server.
870 bind_timelimit 30
871 #
872 # The amount of time, in seconds, to wait while performing an LDAP query.
873 timelimit 30
874 #
875 # Must be set or sudo will ignore LDAP; may be specified multiple times.
876 sudoers_base ou=SUDOers,dc=my-domain,dc=com
877 #
878 # verbose sudoers matching from ldap
879 #sudoers_debug 2
880 #
881 # Enable support for time-based entries in sudoers.
882 #sudoers_timed yes
883 #
884 # optional proxy credentials
885 #binddn <who to search as>
886 #bindpw <password>
887 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
888 #
889 # LDAP protocol version, defaults to 3
890 #ldap_version 3
891 #
892 # Define if you want to use an encrypted LDAP connection.
893 # Typically, you must also set the port to 636 (ldaps).
894 #ssl on
895 #
896 # Define if you want to use port 389 and switch to
897 # encryption before the bind credentials are sent.
898 # Only supported by LDAP servers that support the start_tls
899 # extension such as OpenLDAP.
900 #ssl start_tls
901 #
902 # Additional TLS options follow that allow tweaking of the
903 # SSL/TLS connection.
904 #
905 #tls_checkpeer yes # verify server SSL certificate
906 #tls_checkpeer no # ignore server SSL certificate
907 #
908 # If you enable tls_checkpeer, specify either tls_cacertfile
909 # or tls_cacertdir. Only supported when using OpenLDAP.
910 #
911 #tls_cacertfile /etc/certs/trusted_signers.pem
912 #tls_cacertdir /etc/certs
913 #
914 # For systems that don't have /dev/random
915 # use this along with PRNGD or EGD.pl to seed the
916 # random number pool to generate cryptographic session keys.
917 # Only supported when using OpenLDAP.
918 #
919 #tls_randfile /etc/egd-pool
920 #
921 # You may restrict which ciphers are used. Consult your SSL
922 # documentation for which options go here.
923 # Only supported when using OpenLDAP.
924 #
925 #tls_ciphers <cipher-list>
926 #
927 # Sudo can provide a client certificate when communicating to
928 # the LDAP server.
929 # Tips:
930 # * Enable both lines at the same time.
931 # * Do not password protect the key file.
932 # * Ensure the keyfile is only readable by root.
933 #
934 # For OpenLDAP:
935 #tls_cert /etc/certs/client_cert.pem
936 #tls_key /etc/certs/client_key.pem
937 #
938 # For Netscape-derived LDAP, tls_cert and tls_key may specify either
939 # a directory, in which case the files in the directory must have the
940 # default names (e.g., cert8.db and key4.db), or the path to the cert
941 # and key files themselves. However, a bug in version 5.0 of the LDAP
942 # SDK will prevent specific file names from working. For this reason
943 # it is suggested that tls_cert and tls_key be set to a directory,
944 # not a file name.
945 #
946 # The certificate database specified by tls_cert may contain CA certs
947 # and/or the client's cert. If the client's cert is included, tls_key
948 # should be specified as well.
949 # For backward compatibility, "sslpath" may be used in place of tls_cert.
950 #tls_cert /var/ldap
951 #tls_key /var/ldap
952 #
953 # If using SASL authentication for LDAP (OpenSSL)
954 # use_sasl yes
955 # sasl_auth_id <SASL user name>
956 # rootuse_sasl yes
957 # rootsasl_auth_id <SASL user name for root access>
958 # sasl_secprops none
959 # krb5_ccname /etc/.ldapcache
960 Sudoers schema for OpenLDAP
962 The following schema, in OpenLDAP format, is included with sudo source
963 and binary distributions as schema.OpenLDAP. Simply copy it to the
964 schema directory (e.g., /etc/openldap/schema), add the proper include
965 line in slapd.conf and restart slapd. Sites using the optional on-line
966 configuration supported by OpenLDAP 2.3 and higher should apply the
967 schema.olcSudo file instead.
968 attributetype ( 1.3.6.1.4.1.15953.9.1.1
970 NAME 'sudoUser'
971 DESC 'User(s) who may run sudo'
972 EQUALITY caseExactMatch
973 SUBSTR caseExactSubstringsMatch
974 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
975 attributetype ( 1.3.6.1.4.1.15953.9.1.2
977 NAME 'sudoHost'
978 DESC 'Host(s) who may run sudo'
979 EQUALITY caseExactIA5Match
980 SUBSTR caseExactIA5SubstringsMatch
981 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
982 attributetype ( 1.3.6.1.4.1.15953.9.1.3
984 NAME 'sudoCommand'
985 DESC 'Command(s) to be executed by sudo'
986 EQUALITY caseExactIA5Match
987 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
988 attributetype ( 1.3.6.1.4.1.15953.9.1.4
990 NAME 'sudoRunAs'
991 DESC 'User(s) impersonated by sudo'
992 EQUALITY caseExactIA5Match
993 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
994 attributetype ( 1.3.6.1.4.1.15953.9.1.5
996 NAME 'sudoOption'
997 DESC 'Options(s) followed by sudo'
998 EQUALITY caseExactIA5Match
999 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1000 attributetype ( 1.3.6.1.4.1.15953.9.1.6
1002 NAME 'sudoRunAsUser'
1003 DESC 'User(s) impersonated by sudo'
1004 EQUALITY caseExactMatch
1005 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1006 attributetype ( 1.3.6.1.4.1.15953.9.1.7
1008 NAME 'sudoRunAsGroup'
1009 DESC 'Group(s) impersonated by sudo'
1010 EQUALITY caseExactMatch
1011 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1012 attributetype ( 1.3.6.1.4.1.15953.9.1.8
1014 NAME 'sudoNotBefore'
1015 DESC 'Start of time interval for which the entry is valid'
1016 EQUALITY generalizedTimeMatch
1017 ORDERING generalizedTimeOrderingMatch
1018 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1019 attributetype ( 1.3.6.1.4.1.15953.9.1.9
1021 NAME 'sudoNotAfter'
1022 DESC 'End of time interval for which the entry is valid'
1023 EQUALITY generalizedTimeMatch
1024 ORDERING generalizedTimeOrderingMatch
1025 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1026 attributetype ( 1.3.6.1.4.1.15953.9.1.10
1028 NAME 'sudoOrder'
1029 DESC 'an integer to order the sudoRole entries'
1030 EQUALITY integerMatch
1031 ORDERING integerOrderingMatch
1032 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
1033 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
1035 DESC 'Sudoer Entries'
1036 MUST ( cn )
1037 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
1038 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
1039 sudoOrder $ description )
1040 )
1041
1043 cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
1044
1046 Many people have worked on sudo over the years; this version consists of
1047 code written primarily by:
1048 Todd C. Miller
1050 See the CONTRIBUTORS.md file in the sudo distribution
1052 (https://www.sudo.ws/about/contributors/) for an exhaustive list of peo‐
1053 ple who have contributed to sudo.
1054
1056 There are differences in the way that LDAP-based sudoers is parsed com‐
1057 pared to file-based sudoers. See the Differences between LDAP and
1058 non-LDAP sudoers section for more information.
1059
1061 If you believe you have found a bug in sudo, you can submit a bug report
1062 at https://bugzilla.sudo.ws/
1063
1065 Limited free support is available via the sudo-users mailing list, see
1066 https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
1067 the archives.
1068
1070 sudo is provided “AS IS” and any express or implied warranties, includ‐
1071 ing, but not limited to, the implied warranties of merchantability and
1072 fitness for a particular purpose are disclaimed. See the LICENSE.md file
1073 distributed with sudo or https://www.sudo.ws/about/license/ for complete
1074 details.
1075Sudo 1.9.14p3 June 7, 2023 Sudo 1.9.14p3