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 • sudo no longer exits if there is a typo in sudoers. It is not possi‐
18 ble to load LDAP data into the server that does not conform to the su‐
19 doers schema, so proper syntax is guaranteed. It is still possible to
20 have typos in a user or host name, but this will not prevent sudo from
21 running.
22 • It is possible to specify per-entry options that override the global
24 default options. /etc/sudoers only supports default options and lim‐
25 ited options associated with user/host/commands/aliases. The syntax
26 is complicated and can be difficult for users to understand. Placing
27 the options directly in the entry is more natural.
28 • The visudo program is no longer needed. visudo provides locking and
30 syntax checking of the /etc/sudoers file. Since LDAP updates are
31 atomic, locking is no longer necessary. Because syntax is checked
32 when the data is inserted into LDAP, there is no need for a special‐
33 ized tool to check syntax.
34 SUDOers LDAP container
36 The sudoers configuration is contained in the ou=SUDOers LDAP container.
37 Sudo first looks for the cn=defaults entry in the SUDOers container. If
39 found, the multi-valued sudoOption attribute is parsed in the same manner
40 as a global Defaults line in /etc/sudoers. In the following example, the
41 SSH_AUTH_SOCK variable will be preserved in the environment for all
42 users.
43 dn: cn=defaults,ou=SUDOers,dc=my-domain,dc=com
45 objectClass: top
46 objectClass: sudoRole
47 cn: defaults
48 description: Default sudoOption's go here
49 sudoOption: env_keep+=SSH_AUTH_SOCK
50 The equivalent of a sudoer in LDAP is a sudoRole. It consists of the
52 following attributes:
53 sudoUser
55 A user name, user-ID (prefixed with ‘#’), Unix group name or ID
56 (prefixed with ‘%’ or ‘%#’ respectively), user netgroup (prefixed
57 with ‘+’), or non-Unix group name or ID (prefixed with ‘%:’ or
58 ‘%:#’ respectively). User netgroups are matched using the user and
59 domain members only; the host member is not used when matching.
60 Non-Unix group support is only available when an appropriate
61 group_plugin is defined in the global defaults sudoRole object.
62 sudoHost
64 A host name, IP address, IP network, or host netgroup (prefixed
65 with a ‘+’). The special value ALL will match any host. Host net‐
66 groups are matched using the host (both qualified and unqualified)
67 and domain members only; the user member is not used when matching.
68 If a sudoHost entry is preceded by an exclamation point, ‘!’, and
69 the entry matches, the sudoRole in which it resides will be ig‐
70 nored. Negated sudoHost entries are only supported by version
71 1.8.18 or higher.
72 sudoCommand
74 A fully-qualified Unix command name with optional command line ar‐
75 guments, potentially including globbing characters (aka wild
76 cards). If a command name is preceded by an exclamation point,
77 ‘!’, the user will be prohibited from running that command.
78 The built-in command “sudoedit” is used to permit a user to run
80 sudo with the -e option (or as sudoedit). It may take command line
81 arguments just as a normal command does. Note that “sudoedit” is a
82 command built into sudo itself and must be specified in without a
83 leading path.
84 The special value ALL will match any command.
86 If a command name is prefixed with a SHA-2 digest, it will only be
88 allowed if the digest matches. This may be useful in situations
89 where the user invoking sudo has write access to the command or its
90 parent directory. The following digest formats are supported:
91 sha224, sha256, sha384 and sha512. The digest name must be fol‐
92 lowed by a colon (‘:’) and then the actual digest, in either hex or
93 base64 format. For example, given the following value for sudoCom‐
94 mand:
95 sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
97 The user may only run /bin/ls if its sha224 digest matches the
99 specified value. Command digests are only supported by version
100 1.8.7 or higher.
101 sudoOption
103 Identical in function to the global options described above, but
104 specific to the sudoRole in which it resides.
105 sudoRunAsUser
107 A user name or uid (prefixed with ‘#’) that commands may be run as
108 or a Unix group (prefixed with a ‘%’) or user netgroup (prefixed
109 with a ‘+’) that contains a list of users that commands may be run
110 as. The special value ALL will match any user. If a sudoRunAsUser
111 entry is preceded by an exclamation point, ‘!’, and the entry
112 matches, the sudoRole in which it resides will be ignored. If
113 sudoRunAsUser is specified but empty, it will match the invoking
114 user. If neither sudoRunAsUser nor sudoRunAsGroup are present, the
115 value of the runas_default sudoOption is used (defaults to root).
116 The sudoRunAsUser attribute is only available in sudo versions
118 1.7.0 and higher. Older versions of sudo use the sudoRunAs attri‐
119 bute instead. Negated sudoRunAsUser entries are only supported by
120 version 1.8.26 or higher.
121 sudoRunAsGroup
123 A Unix group or gid (prefixed with ‘#’) that commands may be run
124 as. The special value ALL will match any group. If a
125 sudoRunAsGroup entry is preceded by an exclamation point, ‘!’, and
126 the entry matches, the sudoRole in which it resides will be ig‐
127 nored.
128 The sudoRunAsGroup attribute is only available in sudo versions
130 1.7.0 and higher. Negated sudoRunAsGroup entries are only sup‐
131 ported by version 1.8.26 or higher.
132 sudoNotBefore
134 A timestamp in the form yyyymmddHHMMSSZ that can be used to provide
135 a start date/time for when the sudoRole will be valid. If multiple
136 sudoNotBefore entries are present, the earliest is used. Note that
137 timestamps must be in Coordinated Universal Time (UTC), not the lo‐
138 cal timezone. The minute and seconds portions are optional, but
139 some LDAP servers require that they be present (contrary to the
140 RFC).
141 The sudoNotBefore attribute is only available in sudo versions
143 1.7.5 and higher and must be explicitly enabled via the
144 SUDOERS_TIMED option in /etc/ldap.conf.
145 sudoNotAfter
147 A timestamp in the form yyyymmddHHMMSSZ that indicates an expira‐
148 tion date/time, after which the sudoRole will no longer be valid.
149 If multiple sudoNotAfter entries are present, the last one is used.
150 Note that timestamps must be in Coordinated Universal Time (UTC),
151 not the local timezone. The minute and seconds portions are op‐
152 tional, but some LDAP servers require that they be present (con‐
153 trary to the RFC).
154 The sudoNotAfter attribute is only available in sudo versions 1.7.5
156 and higher and must be explicitly enabled via the SUDOERS_TIMED op‐
157 tion in /etc/ldap.conf.
158 sudoOrder
160 The sudoRole entries retrieved from the LDAP directory have no in‐
161 herent order. The sudoOrder attribute is an integer (or floating
162 point value for LDAP servers that support it) that is used to sort
163 the matching entries. This allows LDAP-based sudoers entries to
164 more closely mimic the behavior of the sudoers file, where the or‐
165 der of the entries influences the result. If multiple entries
166 match, the entry with the highest sudoOrder attribute is chosen.
167 This corresponds to the “last match” behavior of the sudoers file.
168 If the sudoOrder attribute is not present, a value of 0 is assumed.
169 The sudoOrder attribute is only available in sudo versions 1.7.5
171 and higher.
172 Each attribute listed above should contain a single value, but there may
174 be multiple instances of each attribute type. A sudoRole must contain at
175 least one sudoUser, sudoHost and sudoCommand.
176 The following example allows users in group wheel to run any command on
178 any host via sudo:
179 dn: cn=%wheel,ou=SUDOers,dc=my-domain,dc=com
181 objectClass: top
182 objectClass: sudoRole
183 cn: %wheel
184 sudoUser: %wheel
185 sudoHost: ALL
186 sudoCommand: ALL
187 Anatomy of LDAP sudoers lookup
189 When looking up a sudoer using LDAP there are only two or three LDAP
190 queries per invocation. The first query is to parse the global options.
191 The second is to match against the user's name and the groups that the
192 user belongs to. (The special ALL tag is matched in this query too.) If
193 no match is returned for the user's name and groups, a third query re‐
194 turns all entries containing user netgroups and other non-Unix groups and
195 checks to see if the user belongs to any of them.
196 If timed entries are enabled with the SUDOERS_TIMED configuration direc‐
198 tive, the LDAP queries include a sub-filter that limits retrieval to en‐
199 tries that satisfy the time constraints, if any.
200 If the NETGROUP_BASE configuration directive is present (see Configuring
202 ldap.conf below), queries are performed to determine the list of net‐
203 groups the user belongs to before the sudoers query. This makes it pos‐
204 sible to include netgroups in the sudoers query string in the same manner
205 as Unix groups. The third query mentioned above is not performed unless
206 a group provider plugin is also configured. The actual LDAP queries per‐
207 formed by sudo are as follows:
208 1. Match all nisNetgroup records with a nisNetgroupTriple containing
210 the user, host and NIS domain. The query will match
211 nisNetgroupTriple entries with either the short or long form of the
212 host name or no host name specified in the tuple. If the NIS domain
213 is set, the query will match only match entries that include the do‐
214 main or for which there is no domain present. If the NIS domain is
215 not set, a wildcard is used to match any domain name but be aware
216 that the NIS schema used by some LDAP servers may not support wild
217 cards for nisNetgroupTriple.
218 2. Repeated queries are performed to find any nested nisNetgroup
220 records with a memberNisNetgroup entry that refers to an already-
221 matched record.
222 For sites with a large number of netgroups, using NETGROUP_BASE can sig‐
224 nificantly speed up sudo's execution time.
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 Another difference is that it is not possible to use negation in a su‐
279 doUser, sudoRunAsUser or sudoRunAsGroup attribute. For example, the fol‐
280 lowing attributes do not behave the way one might expect.
281 # does not match all but joe
283 # rather, does not match anyone
284 sudoUser: !joe
285 # does not match all but joe
287 # rather, matches everyone including Joe
288 sudoUser: ALL
289 sudoUser: !joe
290 Converting between file-based and LDAP sudoers
292 The cvtsudoers(1) utility can be used to convert between file-based and
293 LDAP sudoers. However, there are features in the file-based sudoers that
294 have no equivalent in LDAP-based sudoers (and vice versa). These cannot
295 be converted automatically.
296 For example, a Cmnd_Alias in a sudoers file may be converted to a
298 sudoRole that contains multiple commands. Multiple users and/or groups
299 may be assigned to the sudoRole.
300 Also, host, user, runas and command-based Defaults entries are not sup‐
302 ported. However, a sudoRole may contain one or more sudoOption at‐
303 tributes which can often serve the same purpose.
304 Consider the following sudoers lines:
306 Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less
308 Defaults!PAGERS noexec
309 alice, bob ALL = ALL
310 In this example, alice and bob are allowed to run all commands, but the
312 commands listed in PAGERS will have the noexec flag set, preventing shell
313 escapes.
314 When converting this to LDAP, two sudoRole objects can be used:
316 dn: cn=PAGERS,ou=SUDOers,dc=my-domain,dc=com
318 objectClass: top
319 objectClass: sudoRole
320 cn: PAGERS
321 sudoUser: alice
322 sudoUser: bob
323 sudoHost: ALL
324 sudoCommand: /usr/bin/more
325 sudoCommand: /usr/bin/pg
326 sudoCommand: /usr/bin/less
327 sudoOption: noexec
328 sudoOrder: 900
329 dn: cn=ADMINS,ou=SUDOers,dc=my-domain,dc=com
331 objectClass: top
332 objectClass: sudoRole
333 cn: ADMINS
334 sudoUser: alice
335 sudoUser: bob
336 sudoHost: ALL
337 sudoCommand: ALL
338 sudoOrder: 100
339 In the LDAP version, the sudoOrder attribute is used to guarantee that
341 the PAGERS sudoRole with noexec has precedence. Unlike the sudoers ver‐
342 sion, the LDAP version requires that all users for whom the restriction
343 should apply be assigned to the PAGERS sudoRole. Using a Unix group or
344 netgroup in PAGERS rather than listing each user would make this easier
345 to maintain.
346 Per-user Defaults entries can be emulated by using one or more sudoOption
348 attributes in a sudoRole. Consider the following sudoers lines:
349 User_Alias ADMINS = john, sally
351 Defaults:ADMINS !authenticate
352 ADMINS ALL = (ALL:ALL) ALL
353 In this example, john and sally are allowed to run any command as any
355 user or group.
356 When converting this to LDAP, we can use a Unix group instead of the
358 User_Alias.
359 dn: cn=admins,ou=SUDOers,dc=my-domain,dc=com
361 objectClass: top
362 objectClass: sudoRole
363 cn: admins
364 sudoUser: %admin
365 sudoHost: ALL
366 sudoRunAsUser: ALL
367 sudoRunAsGroup: ALL
368 sudoCommand: ALL
369 sudoOption: !authenticate
370 This assumes that users john and sally are members of the “admins” Unix
372 group.
373 Sudoers schema
375 In order to use sudo's LDAP support, the sudo schema must be installed on
376 your LDAP server. In addition, be sure to index the sudoUser attribute.
377 The sudo distribution includes versions of the sudoers schema for multi‐
379 ple LDAP servers:
380 schema.OpenLDAP
382 OpenLDAP slapd and OpenBSD ldapd
383 schema.olcSudo
385 OpenLDAP slapd 2.3 and higher when on-line configuration is enabled
386 schema.iPlanet
388 Netscape-derived servers such as the iPlanet, Oracle, and 389 Di‐
389 rectory Servers
390 schema.ActiveDirectory
392 Microsoft Active Directory
393 The schema in OpenLDAP format is also included in the EXAMPLES section.
395 Configuring ldap.conf
397 Sudo reads the /etc/ldap.conf file for LDAP-specific configuration. Typ‐
398 ically, this file is shared between different LDAP-aware clients. As
399 such, most of the settings are not sudo-specific. Note that sudo parses
400 /etc/ldap.conf itself and may support options that differ from those de‐
401 scribed in the system's ldap.conf(5) manual. The path to ldap.conf may
402 be overridden via the ldap_conf plugin argument in sudo.conf(5).
403 Also note that on systems using the OpenLDAP libraries, default values
405 specified in /etc/openldap/ldap.conf or the user's .ldaprc files are not
406 used.
407 sudo supports a variety of LDAP library implementations, including OpenL‐
409 DAP, Netscape-derived (also used by Solaris and HP-UX), and IBM LDAP (aka
410 Tivoli). Some options are specific to certain LDAP implementations or
411 have implementation-specific behavior. These differences are noted below
412 where applicable.
413 Only those options explicitly listed in /etc/ldap.conf as being supported
415 by sudo are honored. Configuration options are listed below in upper
416 case but are parsed in a case-independent manner.
417 Lines beginning with a pound sign (‘#’) are ignored. Leading white space
419 is removed from the beginning of lines.
420 BIND_TIMELIMIT seconds
422 The BIND_TIMELIMIT parameter specifies the amount of time, in sec‐
423 onds, to wait while trying to connect to an LDAP server. If multi‐
424 ple URIs or HOSTs are specified, this is the amount of time to wait
425 before trying the next one in the list.
426 BINDDN DN
428 The BINDDN parameter specifies the identity, in the form of a Dis‐
429 tinguished Name (DN), to use when performing LDAP operations. If
430 not specified, LDAP operations are performed with an anonymous
431 identity. By default, most LDAP servers will allow anonymous ac‐
432 cess.
433 BINDPW secret
435 The BINDPW parameter specifies the password to use when performing
436 LDAP operations. This is typically used in conjunction with the
437 BINDDN parameter. The secret may be a plain text password or a
438 base64-encoded string with a “base64:” prefix. For example:
439 BINDPW base64:dGVzdA==
441 If a plain text password is used, it should be a simple string
443 without quotes. Plain text passwords may not include the comment
444 character (‘#’) and the escaping of special characters with a back‐
445 slash (‘\’) is not supported.
446 DEREF never/searching/finding/always
448 How alias dereferencing is to be performed when searching. See the
449 ldap.conf(5) manual for a full description of this option.
450 HOST name[:port] ...
452 If no URI is specified (see below), the HOST parameter specifies a
453 white space-delimited list of LDAP servers to connect to. Each
454 host may include an optional port separated by a colon (‘:’). The
455 HOST parameter is deprecated in favor of the URI specification and
456 is included for backward compatibility only.
457 KRB5_CCNAME file name
459 The path to the Kerberos 5 credential cache to use when authenti‐
460 cating with the remote server.
461 This option is only relevant when using SASL authentication (see
463 below).
464 LDAP_VERSION number
466 The version of the LDAP protocol to use when connecting to the
467 server. The default value is protocol version 3.
468 NETGROUP_BASE base
470 The base DN to use when performing LDAP netgroup queries. Typi‐
471 cally this is of the form ou=netgroup,dc=my-domain,dc=com for the
472 domain my-domain.com. Multiple NETGROUP_BASE lines may be speci‐
473 fied, in which case they are queried in the order specified.
474 This option can be used to query a user's netgroups directly via
476 LDAP which is usually faster than fetching every sudoRole object
477 containing a sudoUser that begins with a ‘+’ prefix. The NIS
478 schema used by some LDAP servers need a modification to support
479 querying the nisNetgroup object by its nisNetgroupTriple member.
480 OpenLDAP's slapd requires the following change to the
481 nisNetgroupTriple attribute:
482 attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
484 DESC 'Netgroup triple'
485 EQUALITY caseIgnoreIA5Match
486 SUBSTR caseIgnoreIA5SubstringsMatch
487 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
488 NETGROUP_SEARCH_FILTER ldap_filter
490 An LDAP filter which is used to restrict the set of records re‐
491 turned when performing an LDAP netgroup query. Typically, this is
492 of the form attribute=value or
493 (&(attribute=value)(attribute2=value2)). The default search filter
494 is: objectClass=nisNetgroup. If ldap_filter is omitted, no search
495 filter will be used.
496 This option is only used when querying netgroups directly via LDAP.
498 NETWORK_TIMEOUT seconds
500 An alias for BIND_TIMELIMIT provided for OpenLDAP compatibility.
501 PORT port_number
503 If no URI is specified, the PORT parameter specifies the default
504 port to connect to on the LDAP server if a HOST parameter does not
505 specify the port itself. If no PORT parameter is used, the default
506 is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
507 PORT parameter is deprecated in favor of the URI specification and
508 is included for backward compatibility only.
509 ROOTBINDDN DN
511 The ROOTBINDDN parameter specifies the identity, in the form of a
512 Distinguished Name (DN), to use when performing privileged LDAP op‐
513 erations, such as sudoers queries. The password corresponding to
514 the identity should be stored in the or the path specified by the
515 ldap_secret plugin argument in sudo.conf(5), which defaults to
516 /etc/ldap.secret. If no ROOTBINDDN is specified, the BINDDN iden‐
517 tity is used (if any).
518 ROOTUSE_SASL on/true/yes/off/false/no
520 Enable ROOTUSE_SASL to enable SASL authentication when connecting
521 to an LDAP server from a privileged process, such as sudo.
522 SASL_AUTH_ID identity
524 The SASL user name to use when connecting to the LDAP server. By
525 default, sudo will use an anonymous connection.
526 This option is only relevant when using SASL authentication.
528 SASL_MECH mechanisms
530 A white space-delimited list of SASL authentication mechanisms to
531 use. By default, sudo will use GSSAPI authentication.
532 SASL_SECPROPS none/properties
534 SASL security properties or none for no properties. See the SASL
535 programmer's manual for details.
536 This option is only relevant when using SASL authentication.
538 SSL on/true/yes/off/false/no
540 If the SSL parameter is set to on, true or yes, TLS (SSL) encryp‐
541 tion is always used when communicating with the LDAP server. Typi‐
542 cally, this involves connecting to the server on port 636 (ldaps).
543 SSL start_tls
545 If the SSL parameter is set to start_tls, the LDAP server connec‐
546 tion is initiated normally and TLS encryption is begun before the
547 bind credentials are sent. This has the advantage of not requiring
548 a dedicated port for encrypted communications. This parameter is
549 only supported by LDAP servers that honor the start_tls extension,
550 such as the OpenLDAP and IBM Tivoli Directory servers.
551 SUDOERS_BASE base
553 The base DN to use when performing sudo LDAP queries. Typically
554 this is of the form ou=SUDOers,dc=my-domain,dc=com for the domain
555 my-domain.com. Multiple SUDOERS_BASE lines may be specified, in
556 which case they are queried in the order specified.
557 SUDOERS_DEBUG debug_level
559 This sets the debug level for sudo LDAP queries. Debugging infor‐
560 mation is printed to the standard error. A value of 1 results in a
561 moderate amount of debugging information. A value of 2 shows the
562 results of the matches themselves. This parameter should not be
563 set in a production environment as the extra information is likely
564 to confuse users.
565 The SUDOERS_DEBUG parameter is deprecated and will be removed in a
567 future release. The same information is now logged via the sudo
568 debugging framework using the “ldap” subsystem at priorities diag
569 and info for debug_level values 1 and 2 respectively. See the
570 sudo.conf(5) manual for details on how to configure sudo debugging.
571 SUDOERS_SEARCH_FILTER ldap_filter
573 An LDAP filter which is used to restrict the set of records re‐
574 turned when performing a sudo LDAP query. Typically, this is of
575 the form attribute=value or
576 (&(attribute=value)(attribute2=value2)). The default search filter
577 is: objectClass=sudoRole. If ldap_filter is omitted, no search
578 filter will be used.
579 SUDOERS_TIMED on/true/yes/off/false/no
581 Whether or not to evaluate the sudoNotBefore and sudoNotAfter at‐
582 tributes that implement time-dependent sudoers entries.
583 TIMELIMIT seconds
585 The TIMELIMIT parameter specifies the amount of time, in seconds,
586 to wait for a response to an LDAP query.
587 TIMEOUT seconds
589 The TIMEOUT parameter specifies the amount of time, in seconds, to
590 wait for a response from the various LDAP APIs.
591 TLS_CACERT file name
593 An alias for TLS_CACERTFILE for OpenLDAP compatibility.
594 TLS_CACERTFILE file name
596 The path to a certificate authority bundle which contains the cer‐
597 tificates for all the Certificate Authorities the client knows to
598 be valid, e.g., /etc/ssl/ca-bundle.pem.
599 This option is only supported by the OpenLDAP libraries. Netscape-
601 derived LDAP libraries use the same certificate database for CA and
602 client certificates (see TLS_CERT).
603 TLS_CACERTDIR directory
605 Similar to TLS_CACERTFILE but instead of a file, it is a directory
606 containing individual Certificate Authority certificates, e.g.,
607 /etc/ssl/certs. The directory specified by TLS_CACERTDIR is
608 checked after TLS_CACERTFILE.
609 This option is only supported by the OpenLDAP libraries.
611 TLS_CERT file name
613 The path to a file containing the client certificate which can be
614 used to authenticate the client to the LDAP server. The certifi‐
615 cate type depends on the LDAP libraries used.
616 OpenLDAP:
618 tls_cert /etc/ssl/client_cert.pem
619 Netscape-derived:
621 tls_cert /var/ldap/cert7.db
622 IBM LDAP:
624 Unused, the key database specified by TLS_KEY contains both
625 keys and certificates.
626 When using Netscape-derived libraries, this file may also contain
628 Certificate Authority certificates.
629 TLS_CHECKPEER on/true/yes/off/false/no
631 If enabled, TLS_CHECKPEER will cause the LDAP server's TLS certifi‐
632 cated to be verified. If the server's TLS certificate cannot be
633 verified (usually because it is signed by an unknown certificate
634 authority), sudo will be unable to connect to it. If TLS_CHECKPEER
635 is disabled, no check is made. Note that disabling the check cre‐
636 ates an opportunity for man-in-the-middle attacks since the
637 server's identity will not be authenticated. If possible, the CA's
638 certificate should be installed locally so it can be verified.
639 This option is not supported by the IBM LDAP libraries.
641 TLS_KEY file name
643 The path to a file containing the private key which matches the
644 certificate specified by TLS_CERT. The private key must not be
645 password-protected. The key type depends on the LDAP libraries
646 used.
647 OpenLDAP:
649 tls_key /etc/ssl/client_key.pem
650 Netscape-derived:
652 tls_key /var/ldap/key3.db
653 IBM LDAP:
655 tls_key /usr/ldap/ldapkey.kdb
656 When using IBM LDAP libraries, this file may also contain Certifi‐
658 cate Authority and client certificates and may be encrypted.
659 TLS_CIPHERS cipher list
661 The TLS_CIPHERS parameter allows the administer to restrict which
662 encryption algorithms may be used for TLS (SSL) connections. See
663 the OpenLDAP or IBM Tivoli Directory Server manual for a list of
664 valid ciphers.
665 This option is not supported by Netscape-derived libraries.
667 TLS_KEYPW secret
669 The TLS_KEYPW contains the password used to decrypt the key data‐
670 base on clients using the IBM LDAP library. The secret may be a
671 plain text password or a base64-encoded string with a “base64:”
672 prefix. For example:
673 TLS_KEYPW base64:dGVzdA==
675 If a plain text password is used, it should be a simple string
677 without quotes. Plain text passwords may not include the comment
678 character (‘#’) and the escaping of special characters with a back‐
679 slash (‘\’) is not supported. If this option is used,
680 /etc/ldap.conf must not be world-readable to avoid exposing the
681 password. Alternately, a stash file can be used to store the pass‐
682 word in encrypted form (see below).
683 If no TLS_KEYPW is specified, a stash file will be used if it ex‐
685 ists. The stash file must have the same path as the file specified
686 by TLS_KEY, but use a .sth file extension instead of .kdb, e.g.,
687 ldapkey.sth. The default ldapkey.kdb that ships with the IBM
688 Tivoli Directory Server is encrypted with the password
689 ssl_password. The gsk8capicmd utility can be used to manage the
690 key database and create a stash file.
691 This option is only supported by the IBM LDAP libraries.
693 TLS_REQCERT level
695 The TLS_REQCERT parameter controls how the LDAP server's TLS cer‐
696 tificated will be verified (if at all). If the server's TLS cer‐
697 tificate cannot be verified (usually because it is signed by an un‐
698 known certificate authority), sudo will be unable to connect to it.
699 The following level values are supported:
700 never The server certificate will not be requested or
702 checked.
703 allow The server certificate will be requested. A missing
705 or invalid certificate is ignored and not considered
706 an error.
707 try The server certificate will be requested. A missing
709 certificate is ignored but an invalid certificate
710 will result in a connection error.
711 demand | hard
713 The server certificate will be requested. A missing
714 or invalid certificate will result in a connection
715 error. This is the default behavior.
716 This option is only supported by the OpenLDAP libraries. Other
718 LDAP libraries only support the TLS_CHECKPEER parameter.
719 TLS_RANDFILE file name
721 The TLS_RANDFILE parameter specifies the path to an entropy source
722 for systems that lack a random device. It is generally used in
723 conjunction with prngd or egd.
724 This option is only supported by the OpenLDAP libraries.
726 URI ldap[s]://[hostname[:port]] ...
728 Specifies a white space-delimited list of one or more URIs describ‐
729 ing the LDAP server(s) to connect to. The protocol may be either
730 ldap ldaps, the latter being for servers that support TLS (SSL) en‐
731 cryption. If no port is specified, the default is port 389 for
732 ldap:// or port 636 for ldaps://. If no hostname is specified,
733 sudo will connect to localhost. Multiple URI lines are treated
734 identically to a URI line containing multiple entries. Only sys‐
735 tems using the OpenSSL libraries support the mixing of ldap:// and
736 ldaps:// URIs. Both the Netscape-derived and IBM LDAP libraries
737 used on most commercial versions of Unix are only capable of sup‐
738 porting one or the other.
739 USE_SASL on/true/yes/off/false/no
741 Enable USE_SASL for LDAP servers that support SASL authentication.
742 ROOTSASL_AUTH_ID identity
744 The SASL user name to use when ROOTUSE_SASL is enabled.
745 See the ldap.conf entry in the EXAMPLES section.
747 Configuring nsswitch.conf
749 Unless it is disabled at build time, sudo consults the Name Service
750 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
751 Sudo looks for a line beginning with sudoers: and uses this to determine
752 the search order. Note that by default, sudo does not stop searching af‐
753 ter the first match and later matches take precedence over earlier ones
754 (unless [SUCCESS=return] is used, see below). The following sources are
755 recognized:
756 files read sudoers from /etc/sudoers
758 ldap read sudoers from LDAP
759 In addition, a subset of nsswitch.conf-style action statements is sup‐
761 ported, specifically [SUCCESS=return] and [NOTFOUND=return]. These will
762 unconditionally terminate the search if the user was either found
763 ([SUCCESS=return]) or not found ([NOTFOUND=return]) in the immediately
764 preceding source. Other action statements tokens are not supported, nor
765 is test negation with ‘!’.
766 To consult LDAP first followed by the local sudoers file (if it exists),
768 use:
769 sudoers: ldap files
771 To consult LDAP only when no match is found in the local sudoers file (if
773 it exists), use:
774 sudoers: files [SUCCESS=return] ldap
776 The local sudoers file can be ignored completely by using:
778 sudoers: ldap
780 If the /etc/nsswitch.conf file is not present or there is no sudoers
782 line, the following default is assumed:
783 sudoers: files
785 Note that /etc/nsswitch.conf is supported even when the underlying oper‐
787 ating system does not use an nsswitch.conf file, except on AIX (see be‐
788 low).
789 Configuring netsvc.conf
791 On AIX systems, the /etc/netsvc.conf file is consulted instead of
792 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
793 nsswitch.conf; information in the previous section unrelated to the file
794 format itself still applies.
795 To consult LDAP first followed by the local sudoers file (if it exists),
797 use:
798 sudoers = ldap, files
800 The local sudoers file can be ignored completely by using:
802 sudoers = ldap
804 To treat LDAP as authoritative and only use the local sudoers file if the
806 user is not present in LDAP, use:
807 sudoers = ldap = auth, files
809 Note that in the above example, the auth qualifier only affects user
811 lookups; both LDAP and sudoers will be queried for Defaults entries.
812 If the /etc/netsvc.conf file is not present or there is no sudoers line,
814 the following default is assumed:
815 sudoers = files
817 Integration with sssd
819 On systems with the System Security Services Daemon (SSSD) and where sudo
820 has been built with SSSD support, it is possible to use SSSD to cache
821 LDAP sudoers rules. To use SSSD as the sudoers source, you should use
822 sss instead of ldap for the sudoers entry in /etc/nsswitch.conf. Note
823 that the /etc/ldap.conf file is not used by the SSSD sudo back end.
824 Please see sssd-sudo(5) for more information on configuring sudo to work
825 with SSSD.
826
828 /etc/ldap.conf LDAP configuration file
829 /etc/nsswitch.conf determines sudoers source order
831 /etc/netsvc.conf determines sudoers source order on AIX
833
835 Example ldap.conf
836 # Either specify one or more URIs or one or more host:port pairs.
837 # If neither is specified sudo will default to localhost, port 389.
838 #
839 #host ldapserver
840 #host ldapserver1 ldapserver2:390
841 #
842 # Default port if host is specified without one, defaults to 389.
843 #port 389
844 #
845 # URI will override the host and port settings.
846 uri ldap://ldapserver
847 #uri ldaps://secureldapserver
848 #uri ldaps://secureldapserver ldap://ldapserver
849 #
850 # The amount of time, in seconds, to wait while trying to connect to
851 # an LDAP server.
852 bind_timelimit 30
853 #
854 # The amount of time, in seconds, to wait while performing an LDAP query.
855 timelimit 30
856 #
857 # Must be set or sudo will ignore LDAP; may be specified multiple times.
858 sudoers_base ou=SUDOers,dc=my-domain,dc=com
859 #
860 # verbose sudoers matching from ldap
861 #sudoers_debug 2
862 #
863 # Enable support for time-based entries in sudoers.
864 #sudoers_timed yes
865 #
866 # optional proxy credentials
867 #binddn <who to search as>
868 #bindpw <password>
869 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
870 #
871 # LDAP protocol version, defaults to 3
872 #ldap_version 3
873 #
874 # Define if you want to use an encrypted LDAP connection.
875 # Typically, you must also set the port to 636 (ldaps).
876 #ssl on
877 #
878 # Define if you want to use port 389 and switch to
879 # encryption before the bind credentials are sent.
880 # Only supported by LDAP servers that support the start_tls
881 # extension such as OpenLDAP.
882 #ssl start_tls
883 #
884 # Additional TLS options follow that allow tweaking of the
885 # SSL/TLS connection.
886 #
887 #tls_checkpeer yes # verify server SSL certificate
888 #tls_checkpeer no # ignore server SSL certificate
889 #
890 # If you enable tls_checkpeer, specify either tls_cacertfile
891 # or tls_cacertdir. Only supported when using OpenLDAP.
892 #
893 #tls_cacertfile /etc/certs/trusted_signers.pem
894 #tls_cacertdir /etc/certs
895 #
896 # For systems that don't have /dev/random
897 # use this along with PRNGD or EGD.pl to seed the
898 # random number pool to generate cryptographic session keys.
899 # Only supported when using OpenLDAP.
900 #
901 #tls_randfile /etc/egd-pool
902 #
903 # You may restrict which ciphers are used. Consult your SSL
904 # documentation for which options go here.
905 # Only supported when using OpenLDAP.
906 #
907 #tls_ciphers <cipher-list>
908 #
909 # Sudo can provide a client certificate when communicating to
910 # the LDAP server.
911 # Tips:
912 # * Enable both lines at the same time.
913 # * Do not password protect the key file.
914 # * Ensure the keyfile is only readable by root.
915 #
916 # For OpenLDAP:
917 #tls_cert /etc/certs/client_cert.pem
918 #tls_key /etc/certs/client_key.pem
919 #
920 # For Netscape-derived LDAP, tls_cert and tls_key may specify either
921 # a directory, in which case the files in the directory must have the
922 # default names (e.g., cert8.db and key4.db), or the path to the cert
923 # and key files themselves. However, a bug in version 5.0 of the LDAP
924 # SDK will prevent specific file names from working. For this reason
925 # it is suggested that tls_cert and tls_key be set to a directory,
926 # not a file name.
927 #
928 # The certificate database specified by tls_cert may contain CA certs
929 # and/or the client's cert. If the client's cert is included, tls_key
930 # should be specified as well.
931 # For backward compatibility, "sslpath" may be used in place of tls_cert.
932 #tls_cert /var/ldap
933 #tls_key /var/ldap
934 #
935 # If using SASL authentication for LDAP (OpenSSL)
936 # use_sasl yes
937 # sasl_auth_id <SASL user name>
938 # rootuse_sasl yes
939 # rootsasl_auth_id <SASL user name for root access>
940 # sasl_secprops none
941 # krb5_ccname /etc/.ldapcache
942 Sudoers schema for OpenLDAP
944 The following schema, in OpenLDAP format, is included with sudo source
945 and binary distributions as schema.OpenLDAP. Simply copy it to the
946 schema directory (e.g., /etc/openldap/schema), add the proper include
947 line in slapd.conf and restart slapd. Sites using the optional on-line
948 configuration supported by OpenLDAP 2.3 and higher should apply the
949 schema.olcSudo file instead.
950 attributetype ( 1.3.6.1.4.1.15953.9.1.1
952 NAME 'sudoUser'
953 DESC 'User(s) who may run sudo'
954 EQUALITY caseExactIA5Match
955 SUBSTR caseExactIA5SubstringsMatch
956 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
957 attributetype ( 1.3.6.1.4.1.15953.9.1.2
959 NAME 'sudoHost'
960 DESC 'Host(s) who may run sudo'
961 EQUALITY caseExactIA5Match
962 SUBSTR caseExactIA5SubstringsMatch
963 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
964 attributetype ( 1.3.6.1.4.1.15953.9.1.3
966 NAME 'sudoCommand'
967 DESC 'Command(s) to be executed by sudo'
968 EQUALITY caseExactIA5Match
969 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
970 attributetype ( 1.3.6.1.4.1.15953.9.1.4
972 NAME 'sudoRunAs'
973 DESC 'User(s) impersonated by sudo'
974 EQUALITY caseExactIA5Match
975 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
976 attributetype ( 1.3.6.1.4.1.15953.9.1.5
978 NAME 'sudoOption'
979 DESC 'Options(s) followed by sudo'
980 EQUALITY caseExactIA5Match
981 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
982 attributetype ( 1.3.6.1.4.1.15953.9.1.6
984 NAME 'sudoRunAsUser'
985 DESC 'User(s) impersonated 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.7
990 NAME 'sudoRunAsGroup'
991 DESC 'Group(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.8
996 NAME 'sudoNotBefore'
997 DESC 'Start of time interval for which the entry is valid'
998 EQUALITY generalizedTimeMatch
999 ORDERING generalizedTimeOrderingMatch
1000 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1001 attributetype ( 1.3.6.1.4.1.15953.9.1.9
1003 NAME 'sudoNotAfter'
1004 DESC 'End of time interval for which the entry is valid'
1005 EQUALITY generalizedTimeMatch
1006 ORDERING generalizedTimeOrderingMatch
1007 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1008 attributetype ( 1.3.6.1.4.1.15953.9.1.10
1010 NAME 'sudoOrder'
1011 DESC 'an integer to order the sudoRole entries'
1012 EQUALITY integerMatch
1013 ORDERING integerOrderingMatch
1014 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
1015 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
1017 DESC 'Sudoer Entries'
1018 MUST ( cn )
1019 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
1020 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
1021 sudoOrder $ description )
1022 )
1023
1025 cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
1026
1028 Many people have worked on sudo over the years; this version consists of
1029 code written primarily by:
1030 Todd C. Miller
1032 See the CONTRIBUTORS file in the sudo distribution
1034 (https://www.sudo.ws/contributors.html) for an exhaustive list of people
1035 who have contributed to sudo.
1036
1038 Note that there are differences in the way that LDAP-based sudoers is
1039 parsed compared to file-based sudoers. See the Differences between LDAP
1040 and non-LDAP sudoers section for more information.
1041
1043 If you feel you have found a bug in sudo, please submit a bug report at
1044 https://bugzilla.sudo.ws/
1045
1047 Limited free support is available via the sudo-users mailing list, see
1048 https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
1049 the archives.
1050
1052 sudo is provided “AS IS” and any express or implied warranties, includ‐
1053 ing, but not limited to, the implied warranties of merchantability and
1054 fitness for a particular purpose are disclaimed. See the LICENSE file
1055 distributed with sudo or https://www.sudo.ws/license.html for complete
1056 details.
1057Sudo 1.9.7p2 April 5, 2021 Sudo 1.9.7p2