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 configuration direc‐
197 tive, the LDAP queries include a sub-filter that limits retrieval to en‐
198 tries that satisfy the time constraints, if any.
199 If the NETGROUP_BASE configuration directive is present (see Configuring
201 ldap.conf below), queries are performed to determine the list of net‐
202 groups the user belongs to before the sudoers query. This makes it pos‐
203 sible to include netgroups in the sudoers query string in the same manner
204 as Unix groups. The third query mentioned above is not performed unless
205 a group provider plugin is also configured. The actual LDAP queries per‐
206 formed 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.
224 Differences between LDAP and non-LDAP sudoers
226 One of the major differences between LDAP and file-based sudoers is that
227 in LDAP, sudo-specific Aliases are not supported.
228 For the most part, there is little need for sudo-specific Aliases. Unix
230 groups, non-Unix groups (via the group_plugin), or user netgroups can be
231 used in place of User_Aliases and Runas_Aliases. Host netgroups can be
232 used in place of Host_Aliases. Since groups and netgroups can also be
233 stored in LDAP there is no real need for sudo-specific aliases.
234 There are also some subtle differences in the way sudoers is handled once
236 in LDAP. Probably the biggest is that according to the RFC, LDAP order‐
237 ing is arbitrary and you cannot expect that Attributes and Entries are
238 returned in any specific order.
239 The order in which different entries are applied can be controlled using
241 the sudoOrder attribute, but there is no way to guarantee the order of
242 attributes within a specific entry. If there are conflicting command
243 rules in an entry, the negative takes precedence. This is called para‐
244 noid behavior (not necessarily the most specific match).
245 Here is an example:
247 # /etc/sudoers:
249 # Allow all commands except shell
250 johnny ALL=(root) ALL,!/bin/sh
251 # Always allows all commands because ALL is matched last
252 puddles ALL=(root) !/bin/sh,ALL
253 # LDAP equivalent of johnny
255 # Allows all commands except shell
256 dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
257 objectClass: sudoRole
258 objectClass: top
259 cn: role1
260 sudoUser: johnny
261 sudoHost: ALL
262 sudoCommand: ALL
263 sudoCommand: !/bin/sh
264 # LDAP equivalent of puddles
266 # Notice that even though ALL comes last, it still behaves like
267 # role1 since the LDAP code assumes the more paranoid configuration
268 dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
269 objectClass: sudoRole
270 objectClass: top
271 cn: role2
272 sudoUser: puddles
273 sudoHost: ALL
274 sudoCommand: !/bin/sh
275 sudoCommand: ALL
276 Converting between file-based and LDAP sudoers
278 The cvtsudoers(1) utility can be used to convert between file-based and
279 LDAP sudoers. However, there are features in the file-based sudoers that
280 have no equivalent in LDAP-based sudoers (and vice versa). These cannot
281 be converted automatically.
282 For example, a Cmnd_Alias in a sudoers file may be converted to a
284 sudoRole that contains multiple commands. Multiple users and/or groups
285 may be assigned to the sudoRole.
286 Also, host, user, runas, and command-based Defaults entries are not sup‐
288 ported. However, a sudoRole may contain one or more sudoOption at‐
289 tributes which can often serve the same purpose.
290 Consider the following sudoers lines:
292 Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less
294 Defaults!PAGERS noexec
295 alice, bob ALL = ALL
296 In this example, alice and bob are allowed to run all commands, but the
298 commands listed in PAGERS will have the noexec flag set, preventing shell
299 escapes.
300 When converting this to LDAP, two sudoRole objects can be used:
302 dn: cn=PAGERS,ou=SUDOers,dc=my-domain,dc=com
304 objectClass: top
305 objectClass: sudoRole
306 cn: PAGERS
307 sudoUser: alice
308 sudoUser: bob
309 sudoHost: ALL
310 sudoCommand: /usr/bin/more
311 sudoCommand: /usr/bin/pg
312 sudoCommand: /usr/bin/less
313 sudoOption: noexec
314 sudoOrder: 900
315 dn: cn=ADMINS,ou=SUDOers,dc=my-domain,dc=com
317 objectClass: top
318 objectClass: sudoRole
319 cn: ADMINS
320 sudoUser: alice
321 sudoUser: bob
322 sudoHost: ALL
323 sudoCommand: ALL
324 sudoOrder: 100
325 In the LDAP version, the sudoOrder attribute is used to guarantee that
327 the PAGERS sudoRole with noexec has precedence. Unlike the sudoers ver‐
328 sion, the LDAP version requires that all users for whom the restriction
329 should apply be assigned to the PAGERS sudoRole. Using a Unix group or
330 netgroup in PAGERS rather than listing each user would make this easier
331 to maintain.
332 Per-user Defaults entries can be emulated by using one or more sudoOption
334 attributes in a sudoRole. Consider the following sudoers lines:
335 User_Alias ADMINS = john, sally
337 Defaults:ADMINS !authenticate
338 ADMINS ALL = (ALL:ALL) ALL
339 In this example, john and sally are allowed to run any command as any
341 user or group.
342 When converting this to LDAP, we can use a Unix group instead of the
344 User_Alias.
345 dn: cn=admins,ou=SUDOers,dc=my-domain,dc=com
347 objectClass: top
348 objectClass: sudoRole
349 cn: admins
350 sudoUser: %admin
351 sudoHost: ALL
352 sudoRunAsUser: ALL
353 sudoRunAsGroup: ALL
354 sudoCommand: ALL
355 sudoOption: !authenticate
356 This assumes that users john and sally are members of the “admins” Unix
358 group.
359 Sudoers schema
361 In order to use sudo's LDAP support, the sudo schema must be installed on
362 your LDAP server. In addition, be sure to index the sudoUser attribute.
363 The sudo distribution includes versions of the sudoers schema for multi‐
365 ple LDAP servers:
366 schema.OpenLDAP
368 OpenLDAP slapd and OpenBSD ldapd
369 schema.olcSudo
371 OpenLDAP slapd 2.3 and higher when on-line configuration is enabled
372 schema.iPlanet
374 Netscape-derived servers such as the iPlanet, Oracle, and 389 Di‐
375 rectory Servers
376 schema.ActiveDirectory
378 Microsoft Active Directory
379 The schema in OpenLDAP format is also included in the EXAMPLES section.
381 Configuring ldap.conf
383 Sudo reads the /etc/ldap.conf file for LDAP-specific configuration. Typ‐
384 ically, this file is shared between different LDAP-aware clients. As
385 such, most of the settings are not sudo-specific. The /etc/ldap.conf file
386 is parsed by sudo itself and may support options that differ from those
387 described in the system's ldap.conf(5) manual. The path to ldap.conf may
388 be overridden via the ldap_conf plugin argument in sudo.conf(5).
389 On systems using the OpenLDAP libraries, default values specified in
391 /etc/openldap/ldap.conf or the user's .ldaprc files are not used.
392 sudo supports a variety of LDAP library implementations, including OpenL‐
394 DAP, Netscape-derived (also used by Solaris and HP-UX), and IBM LDAP (aka
395 Tivoli). Some options are specific to certain LDAP implementations or
396 have implementation-specific behavior. These differences are noted below
397 where applicable.
398 Only those options explicitly listed in /etc/ldap.conf as being supported
400 by sudo are honored. Configuration options are listed below in upper
401 case but are parsed in a case-independent manner.
402 Lines beginning with a pound sign (‘#’) are ignored. Leading white space
404 is removed from the beginning of lines.
405 BIND_TIMELIMIT seconds
407 The BIND_TIMELIMIT parameter specifies the amount of time, in sec‐
408 onds, to wait while trying to connect to an LDAP server. If multi‐
409 ple URIs or HOSTs are specified, this is the amount of time to wait
410 before trying the next one in the list.
411 BINDDN DN
413 The BINDDN parameter specifies the identity, in the form of a Dis‐
414 tinguished Name (DN), to use when performing LDAP operations. If
415 not specified, LDAP operations are performed with an anonymous
416 identity. By default, most LDAP servers will allow anonymous ac‐
417 cess.
418 BINDPW secret
420 The BINDPW parameter specifies the password to use when performing
421 LDAP operations. This is typically used in conjunction with the
422 BINDDN parameter. The secret may be a plaintext password or a
423 base64-encoded string with a “base64:” prefix. For example:
424 BINDPW base64:dGVzdA==
426 If a plaintext password is used, it should be a simple string with‐
428 out quotes. Plain text passwords may not include the comment char‐
429 acter (‘#’) and the escaping of special characters with a backslash
430 (‘\’) is not supported.
431 DEREF never/searching/finding/always
433 How alias dereferencing is to be performed when searching. See the
434 ldap.conf(5) manual for a full description of this option.
435 HOST name[:port] ...
437 If no URI is specified (see below), the HOST parameter specifies a
438 white space-delimited list of LDAP servers to connect to. Each
439 host may include an optional port separated by a colon (‘:’). The
440 HOST parameter is deprecated in favor of the URI specification and
441 is included for backward compatibility only.
442 KRB5_CCNAME file name
444 The path to the Kerberos 5 credential cache to use when authenti‐
445 cating with the remote server.
446 This option is only relevant when using SASL authentication (see
448 below).
449 LDAP_VERSION number
451 The version of the LDAP protocol to use when connecting to the
452 server. The default value is protocol version 3.
453 NETGROUP_BASE base
455 The base DN to use when performing LDAP netgroup queries. Typi‐
456 cally this is of the form ‘ou=netgroup,dc=my-domain,dc=com’ for the
457 domain my-domain.com. Multiple NETGROUP_BASE lines may be speci‐
458 fied, in which case they are queried in the order specified.
459 This option can be used to query a user's netgroups directly via
461 LDAP which is usually faster than fetching every sudoRole object
462 containing a sudoUser that begins with a ‘+’ prefix. The NIS
463 schema used by some LDAP servers need a modification to support
464 querying the nisNetgroup object by its nisNetgroupTriple member.
465 OpenLDAP's slapd requires the following change to the
466 nisNetgroupTriple attribute:
467 attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
469 DESC 'Netgroup triple'
470 EQUALITY caseIgnoreIA5Match
471 SUBSTR caseIgnoreIA5SubstringsMatch
472 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
473 NETGROUP_SEARCH_FILTER ldap_filter
475 An LDAP filter which is used to restrict the set of records re‐
476 turned when performing an LDAP netgroup query. Typically, this is
477 of the form ‘attribute=value’ or
478 ‘(&(attribute=value)(attribute2=value2))’. The default search fil‐
479 ter is: ‘objectClass=nisNetgroup’. If ldap_filter is omitted, no
480 search filter will be used.
481 This option is only used when querying netgroups directly via LDAP.
483 NETWORK_TIMEOUT seconds
485 An alias for BIND_TIMELIMIT provided for OpenLDAP compatibility.
486 PORT port_number
488 If no URI is specified, the PORT parameter specifies the default
489 port to connect to on the LDAP server if a HOST parameter does not
490 specify the port itself. If no PORT parameter is used, the default
491 is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
492 PORT parameter is deprecated in favor of the URI specification and
493 is included for backward compatibility only.
494 ROOTBINDDN DN
496 The ROOTBINDDN parameter specifies the identity, in the form of a
497 Distinguished Name (DN), to use when performing privileged LDAP op‐
498 erations, such as sudoers queries. The password corresponding to
499 the identity should be stored in the or the path specified by the
500 ldap_secret plugin argument in sudo.conf(5), which defaults to
501 /etc/ldap.secret. If no ROOTBINDDN is specified, the BINDDN iden‐
502 tity is used (if any).
503 ROOTUSE_SASL on/true/yes/off/false/no
505 Enable ROOTUSE_SASL to enable SASL authentication when connecting
506 to an LDAP server from a privileged process, such as sudo.
507 SASL_AUTH_ID identity
509 The SASL user name to use when connecting to the LDAP server. By
510 default, sudo will use an anonymous connection.
511 This option is only relevant when using SASL authentication.
513 SASL_MECH mechanisms
515 A white space-delimited list of SASL authentication mechanisms to
516 use. By default, sudo will use GSSAPI authentication.
517 SASL_SECPROPS none/properties
519 SASL security properties or none for no properties. See the SASL
520 programmer's manual for details.
521 This option is only relevant when using SASL authentication.
523 SSL on/true/yes/off/false/no
525 If the SSL parameter is set to on, true, or yes TLS (SSL) encryp‐
526 tion is always used when communicating with the LDAP server. Typi‐
527 cally, this involves connecting to the server on port 636 (ldaps).
528 SSL start_tls
530 If the SSL parameter is set to start_tls, the LDAP server connec‐
531 tion is initiated normally and TLS encryption is begun before the
532 bind credentials are sent. This has the advantage of not requiring
533 a dedicated port for encrypted communications. This parameter is
534 only supported by LDAP servers that honor the start_tls extension,
535 such as the OpenLDAP and IBM Tivoli Directory servers.
536 SUDOERS_BASE base
538 The base DN to use when performing sudo LDAP queries. Typically
539 this is of the form ‘ou=SUDOers,dc=my-domain,dc=com’ for the domain
540 my-domain.com. Multiple SUDOERS_BASE lines may be specified, in
541 which case they are queried in the order specified.
542 SUDOERS_DEBUG debug_level
544 This sets the debug level for sudo LDAP queries. Debugging infor‐
545 mation is printed to the standard error. A value of 1 results in a
546 moderate amount of debugging information. A value of 2 shows the
547 results of the matches themselves. This parameter should not be
548 set in a production environment as the extra information is likely
549 to confuse users.
550 The SUDOERS_DEBUG parameter is deprecated and will be removed in a
552 future release. The same information is now logged via the sudo
553 debugging framework using the “ldap” subsystem at priorities diag
554 and info for debug_level values 1 and 2 respectively. See the
555 sudo.conf(5) manual for details on how to configure sudo debugging.
556 SUDOERS_SEARCH_FILTER ldap_filter
558 An LDAP filter which is used to restrict the set of records re‐
559 turned when performing a sudo LDAP query. Typically, this is of
560 the form ‘attribute=value’ or
561 ‘(&(attribute=value)(attribute2=value2))’. The default search fil‐
562 ter is: ‘objectClass=sudoRole’. If ldap_filter is omitted, no
563 search filter will be used.
564 SUDOERS_TIMED on/true/yes/off/false/no
566 Whether or not to evaluate the sudoNotBefore and sudoNotAfter at‐
567 tributes that implement time-dependent sudoers entries.
568 TIMELIMIT seconds
570 The TIMELIMIT parameter specifies the amount of time, in seconds,
571 to wait for a response to an LDAP query.
572 TIMEOUT seconds
574 The TIMEOUT parameter specifies the amount of time, in seconds, to
575 wait for a response from the various LDAP APIs.
576 TLS_CACERT file name
578 An alias for TLS_CACERTFILE for OpenLDAP compatibility.
579 TLS_CACERTFILE file name
581 The path to a certificate authority bundle which contains the cer‐
582 tificates for all the Certificate Authorities the client knows to
583 be valid, e.g., /etc/ssl/ca-bundle.pem.
584 This option is only supported by the OpenLDAP libraries. Netscape-
586 derived LDAP libraries use the same certificate database for CA and
587 client certificates (see TLS_CERT).
588 TLS_CACERTDIR directory
590 Similar to TLS_CACERTFILE but instead of a file, it is a directory
591 containing individual Certificate Authority certificates, e.g.,
592 /etc/ssl/certs. The directory specified by TLS_CACERTDIR is
593 checked after TLS_CACERTFILE.
594 This option is only supported by the OpenLDAP libraries.
596 TLS_CERT file name
598 The path to a file containing the client certificate which can be
599 used to authenticate the client to the LDAP server. The certifi‐
600 cate type depends on the LDAP libraries used.
601 OpenLDAP:
603 ‘tls_cert /etc/ssl/client_cert.pem’
604 Netscape-derived:
606 ‘tls_cert /var/ldap/cert7.db’
607 IBM LDAP:
609 Unused, the key database specified by TLS_KEY contains both
610 keys and certificates.
611 When using Netscape-derived libraries, this file may also contain
613 Certificate Authority certificates.
614 TLS_CHECKPEER on/true/yes/off/false/no
616 If enabled, TLS_CHECKPEER will cause the LDAP server's TLS certifi‐
617 cated to be verified. If the server's TLS certificate cannot be
618 verified (usually because it is signed by an unknown certificate
619 authority), sudo will be unable to connect to it. If TLS_CHECKPEER
620 is disabled, no check is made. Disabling this check creates an op‐
621 portunity for man-in-the-middle attacks since the server's identity
622 will not be authenticated. If possible, the CA's certificate
623 should be installed locally so it can be verified.
624 This option is not supported by the IBM LDAP libraries.
626 TLS_KEY file name
628 The path to a file containing the private key which matches the
629 certificate specified by TLS_CERT. The private key must not be
630 password-protected. The key type depends on the LDAP libraries
631 used.
632 OpenLDAP:
634 ‘tls_key /etc/ssl/client_key.pem’
635 Netscape-derived:
637 ‘tls_key /var/ldap/key3.db’
638 IBM LDAP:
640 ‘tls_key /usr/ldap/ldapkey.kdb’
641 When using IBM LDAP libraries, this file may also contain Certifi‐
643 cate Authority and client certificates and may be encrypted.
644 TLS_CIPHERS cipher list
646 The TLS_CIPHERS parameter allows the administer to restrict which
647 encryption algorithms may be used for TLS (SSL) connections. See
648 the OpenLDAP or IBM Tivoli Directory Server manual for a list of
649 valid ciphers.
650 This option is not supported by Netscape-derived libraries.
652 TLS_KEYPW secret
654 The TLS_KEYPW contains the password used to decrypt the key data‐
655 base on clients using the IBM LDAP library. The secret may be a
656 plaintext password or a base64-encoded string with a “base64:” pre‐
657 fix. For example:
658 TLS_KEYPW base64:dGVzdA==
660 If a plaintext password is used, it should be a simple string with‐
662 out quotes. Plain text passwords may not include the comment char‐
663 acter (‘#’) and the escaping of special characters with a backslash
664 (‘\’) is not supported. If this option is used, /etc/ldap.conf
665 must not be world-readable to avoid exposing the password. Alter‐
666 nately, a stash file can be used to store the password in encrypted
667 form (see below).
668 If no TLS_KEYPW is specified, a stash file will be used if it ex‐
670 ists. The stash file must have the same path as the file specified
671 by TLS_KEY, but use a ‘.sth’ file extension instead of ‘.kdb’, for
672 example ‘ldapkey.sth’. The default ‘ldapkey.kdb’ that ships with
673 the IBM Tivoli Directory Server is encrypted with the password
674 ‘ssl_password’. The gsk8capicmd utility can be used to manage the
675 key database and create a stash file.
676 This option is only supported by the IBM LDAP libraries.
678 TLS_REQCERT level
680 The TLS_REQCERT parameter controls how the LDAP server's TLS cer‐
681 tificated will be verified (if at all). If the server's TLS cer‐
682 tificate cannot be verified (usually because it is signed by an un‐
683 known certificate authority), sudo will be unable to connect to it.
684 The following level values are supported:
685 never The server certificate will not be requested or
687 checked.
688 allow The server certificate will be requested. A missing
690 or invalid certificate is ignored and not considered
691 an error.
692 try The server certificate will be requested. A missing
694 certificate is ignored but an invalid certificate
695 will result in a connection error.
696 demand | hard
698 The server certificate will be requested. A missing
699 or invalid certificate will result in a connection
700 error. This is the default behavior.
701 This option is only supported by the OpenLDAP libraries. Other
703 LDAP libraries only support the TLS_CHECKPEER parameter.
704 TLS_RANDFILE file name
706 The TLS_RANDFILE parameter specifies the path to an entropy source
707 for systems that lack a random device. It is generally used in
708 conjunction with prngd or egd.
709 This option is only supported by the OpenLDAP libraries.
711 URI ldap[s]://[hostname[:port]] ...
713 Specifies a white space-delimited list of one or more URIs describ‐
714 ing the LDAP server(s) to connect to. The protocol may be either
715 ldap ldaps, the latter being for servers that support TLS (SSL) en‐
716 cryption. If no port is specified, the default is port 389 for
717 ‘ldap://’ or port 636 for ‘ldaps://’. If no hostname is specified,
718 sudo will connect to localhost. Multiple URI lines are treated
719 identically to a URI line containing multiple entries. Only sys‐
720 tems using the OpenSSL libraries support the mixing of ‘ldap://’
721 and ‘ldaps://’ URIs. Both the Netscape-derived and IBM LDAP li‐
722 braries used on most commercial versions of Unix are only capable
723 of supporting one or the other.
724 USE_SASL on/true/yes/off/false/no
726 Enable USE_SASL for LDAP servers that support SASL authentication.
727 ROOTSASL_AUTH_ID identity
729 The SASL user name to use when ROOTUSE_SASL is enabled.
730 See the ldap.conf entry in the EXAMPLES section.
732 Configuring nsswitch.conf
734 Unless it is disabled at build time, sudo consults the Name Service
735 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
736 Sudo looks for a line beginning with sudoers: and uses this to determine
737 the search order. By default, sudo does not stop searching after the
738 first match and later matches take precedence over earlier ones (unless
739 ‘[SUCCESS=return]’ is used, see below). The following sources are recog‐
740 nized:
741 files read sudoers from /etc/sudoers
743 ldap read sudoers from LDAP
744 In addition, a subset of nsswitch.conf-style action statements is sup‐
746 ported, specifically ‘[SUCCESS=return]’ and ‘[NOTFOUND=return]’. These
747 will unconditionally terminate the search if the user was either found
748 ‘[SUCCESS=return]’ or not found ‘[NOTFOUND=return]’ in the immediately
749 preceding source. Other action statements tokens are not supported, nor
750 is test negation with ‘!’.
751 To consult LDAP first followed by the local sudoers file (if it exists),
753 use:
754 sudoers: ldap files
756 To consult LDAP only when no match is found in the local sudoers file (if
758 it exists), use:
759 sudoers: files [SUCCESS=return] ldap
761 The local sudoers file can be ignored completely by using:
763 sudoers: ldap
765 If the /etc/nsswitch.conf file is not present or there is no sudoers
767 line, the following default is assumed:
768 sudoers: files
770 The /etc/nsswitch.conf file is supported even when the underlying operat‐
772 ing system does not support it, except on AIX (see below).
773 Configuring netsvc.conf
775 On AIX systems, the /etc/netsvc.conf file is consulted instead of
776 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
777 nsswitch.conf; information in the previous section unrelated to the file
778 format itself still applies.
779 To consult LDAP first followed by the local sudoers file (if it exists),
781 use:
782 sudoers = ldap, files
784 The local sudoers file can be ignored completely by using:
786 sudoers = ldap
788 To treat LDAP as authoritative and only use the local sudoers file if the
790 user is not present in LDAP, use:
791 sudoers = ldap = auth, files
793 In the above example, the auth qualifier only affects user lookups; both
795 LDAP and sudoers will be queried for Defaults entries.
796 If the /etc/netsvc.conf file is not present or there is no sudoers line,
798 the following default is assumed:
799 sudoers = files
801 Integration with sssd
803 On systems with the System Security Services Daemon (SSSD) and where sudo
804 has been built with SSSD support, it is possible to use SSSD to cache
805 LDAP sudoers rules. To use SSSD as the sudoers source, you should use
806 sss instead of ldap for the sudoers entry in /etc/nsswitch.conf. The
807 /etc/ldap.conf file is not used by the SSSD sudo back end. See
808 sssd-sudo(5) for more information on configuring sudo to work with SSSD.
809
811 /etc/ldap.conf LDAP configuration file
812 /etc/nsswitch.conf determines sudoers source order
814 /etc/netsvc.conf determines sudoers source order on AIX
816
818 Example ldap.conf
819 # Either specify one or more URIs or one or more host:port pairs.
820 # If neither is specified sudo will default to localhost, port 389.
821 #
822 #host ldapserver
823 #host ldapserver1 ldapserver2:390
824 #
825 # Default port if host is specified without one, defaults to 389.
826 #port 389
827 #
828 # URI will override the host and port settings.
829 uri ldap://ldapserver
830 #uri ldaps://secureldapserver
831 #uri ldaps://secureldapserver ldap://ldapserver
832 #
833 # The amount of time, in seconds, to wait while trying to connect to
834 # an LDAP server.
835 bind_timelimit 30
836 #
837 # The amount of time, in seconds, to wait while performing an LDAP query.
838 timelimit 30
839 #
840 # Must be set or sudo will ignore LDAP; may be specified multiple times.
841 sudoers_base ou=SUDOers,dc=my-domain,dc=com
842 #
843 # verbose sudoers matching from ldap
844 #sudoers_debug 2
845 #
846 # Enable support for time-based entries in sudoers.
847 #sudoers_timed yes
848 #
849 # optional proxy credentials
850 #binddn <who to search as>
851 #bindpw <password>
852 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
853 #
854 # LDAP protocol version, defaults to 3
855 #ldap_version 3
856 #
857 # Define if you want to use an encrypted LDAP connection.
858 # Typically, you must also set the port to 636 (ldaps).
859 #ssl on
860 #
861 # Define if you want to use port 389 and switch to
862 # encryption before the bind credentials are sent.
863 # Only supported by LDAP servers that support the start_tls
864 # extension such as OpenLDAP.
865 #ssl start_tls
866 #
867 # Additional TLS options follow that allow tweaking of the
868 # SSL/TLS connection.
869 #
870 #tls_checkpeer yes # verify server SSL certificate
871 #tls_checkpeer no # ignore server SSL certificate
872 #
873 # If you enable tls_checkpeer, specify either tls_cacertfile
874 # or tls_cacertdir. Only supported when using OpenLDAP.
875 #
876 #tls_cacertfile /etc/certs/trusted_signers.pem
877 #tls_cacertdir /etc/certs
878 #
879 # For systems that don't have /dev/random
880 # use this along with PRNGD or EGD.pl to seed the
881 # random number pool to generate cryptographic session keys.
882 # Only supported when using OpenLDAP.
883 #
884 #tls_randfile /etc/egd-pool
885 #
886 # You may restrict which ciphers are used. Consult your SSL
887 # documentation for which options go here.
888 # Only supported when using OpenLDAP.
889 #
890 #tls_ciphers <cipher-list>
891 #
892 # Sudo can provide a client certificate when communicating to
893 # the LDAP server.
894 # Tips:
895 # * Enable both lines at the same time.
896 # * Do not password protect the key file.
897 # * Ensure the keyfile is only readable by root.
898 #
899 # For OpenLDAP:
900 #tls_cert /etc/certs/client_cert.pem
901 #tls_key /etc/certs/client_key.pem
902 #
903 # For Netscape-derived LDAP, tls_cert and tls_key may specify either
904 # a directory, in which case the files in the directory must have the
905 # default names (e.g., cert8.db and key4.db), or the path to the cert
906 # and key files themselves. However, a bug in version 5.0 of the LDAP
907 # SDK will prevent specific file names from working. For this reason
908 # it is suggested that tls_cert and tls_key be set to a directory,
909 # not a file name.
910 #
911 # The certificate database specified by tls_cert may contain CA certs
912 # and/or the client's cert. If the client's cert is included, tls_key
913 # should be specified as well.
914 # For backward compatibility, "sslpath" may be used in place of tls_cert.
915 #tls_cert /var/ldap
916 #tls_key /var/ldap
917 #
918 # If using SASL authentication for LDAP (OpenSSL)
919 # use_sasl yes
920 # sasl_auth_id <SASL user name>
921 # rootuse_sasl yes
922 # rootsasl_auth_id <SASL user name for root access>
923 # sasl_secprops none
924 # krb5_ccname /etc/.ldapcache
925 Sudoers schema for OpenLDAP
927 The following schema, in OpenLDAP format, is included with sudo source
928 and binary distributions as schema.OpenLDAP. Simply copy it to the
929 schema directory (e.g., /etc/openldap/schema), add the proper include
930 line in slapd.conf and restart slapd. Sites using the optional on-line
931 configuration supported by OpenLDAP 2.3 and higher should apply the
932 schema.olcSudo file instead.
933 attributetype ( 1.3.6.1.4.1.15953.9.1.1
935 NAME 'sudoUser'
936 DESC 'User(s) who may run sudo'
937 EQUALITY caseExactMatch
938 SUBSTR caseExactSubstringsMatch
939 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
940 attributetype ( 1.3.6.1.4.1.15953.9.1.2
942 NAME 'sudoHost'
943 DESC 'Host(s) who may run sudo'
944 EQUALITY caseExactIA5Match
945 SUBSTR caseExactIA5SubstringsMatch
946 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
947 attributetype ( 1.3.6.1.4.1.15953.9.1.3
949 NAME 'sudoCommand'
950 DESC 'Command(s) to be executed by sudo'
951 EQUALITY caseExactIA5Match
952 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
953 attributetype ( 1.3.6.1.4.1.15953.9.1.4
955 NAME 'sudoRunAs'
956 DESC 'User(s) impersonated by sudo'
957 EQUALITY caseExactIA5Match
958 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
959 attributetype ( 1.3.6.1.4.1.15953.9.1.5
961 NAME 'sudoOption'
962 DESC 'Options(s) followed by sudo'
963 EQUALITY caseExactIA5Match
964 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
965 attributetype ( 1.3.6.1.4.1.15953.9.1.6
967 NAME 'sudoRunAsUser'
968 DESC 'User(s) impersonated by sudo'
969 EQUALITY caseExactMatch
970 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
971 attributetype ( 1.3.6.1.4.1.15953.9.1.7
973 NAME 'sudoRunAsGroup'
974 DESC 'Group(s) impersonated by sudo'
975 EQUALITY caseExactMatch
976 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
977 attributetype ( 1.3.6.1.4.1.15953.9.1.8
979 NAME 'sudoNotBefore'
980 DESC 'Start of time interval for which the entry is valid'
981 EQUALITY generalizedTimeMatch
982 ORDERING generalizedTimeOrderingMatch
983 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
984 attributetype ( 1.3.6.1.4.1.15953.9.1.9
986 NAME 'sudoNotAfter'
987 DESC 'End of time interval for which the entry is valid'
988 EQUALITY generalizedTimeMatch
989 ORDERING generalizedTimeOrderingMatch
990 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
991 attributetype ( 1.3.6.1.4.1.15953.9.1.10
993 NAME 'sudoOrder'
994 DESC 'an integer to order the sudoRole entries'
995 EQUALITY integerMatch
996 ORDERING integerOrderingMatch
997 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
998 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
1000 DESC 'Sudoer Entries'
1001 MUST ( cn )
1002 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
1003 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
1004 sudoOrder $ description )
1005 )
1006
1008 cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
1009
1011 Many people have worked on sudo over the years; this version consists of
1012 code written primarily by:
1013 Todd C. Miller
1015 See the CONTRIBUTORS.md file in the sudo distribution
1017 (https://www.sudo.ws/about/contributors/) for an exhaustive list of peo‐
1018 ple who have contributed to sudo.
1019
1021 There are differences in the way that LDAP-based sudoers is parsed com‐
1022 pared to file-based sudoers. See the Differences between LDAP and
1023 non-LDAP sudoers section for more information.
1024
1026 If you believe you have found a bug in sudo, you can submit a bug report
1027 at https://bugzilla.sudo.ws/
1028
1030 Limited free support is available via the sudo-users mailing list, see
1031 https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
1032 the archives.
1033
1035 sudo is provided “AS IS” and any express or implied warranties, includ‐
1036 ing, but not limited to, the implied warranties of merchantability and
1037 fitness for a particular purpose are disclaimed. See the LICENSE.md file
1038 distributed with sudo or https://www.sudo.ws/about/license/ for complete
1039 details.
1040Sudo 1.9.12p2 September 13, 2022 Sudo 1.9.12p2