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
19 sudoers schema, so proper syntax is guaranteed. It is still possible
20 to have typos in a user or host name, but this will not prevent sudo
21 from 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
70 ignored. 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
75 arguments, 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
119 attribute instead. Negated sudoRunAsUser entries are only sup‐
120 ported by 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
127 ignored.
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
138 local 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
152 optional, 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
157 option in /etc/ldap.conf.
158 sudoOrder
160 The sudoRole entries retrieved from the LDAP directory have no
161 inherent 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
165 order 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
194 returns all entries containing user netgroups and other non-Unix groups
195 and 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
199 entries 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
214 domain or for which there is no domain present. If the NIS domain
215 is 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
279 sudoUser, sudoRunAsUser or sudoRunAsGroup attribute. For example, the
280 following 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
303 attributes 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
389 Directory 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
401 described 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 Only those options explicitly listed in /etc/ldap.conf as being supported
409 by sudo are honored. Configuration options are listed below in upper
410 case but are parsed in a case-independent manner.
411 Lines beginning with a pound sign (‘#’) are ignored. Leading white space
413 is removed from the beginning of lines.
414 BIND_TIMELIMIT seconds
416 The BIND_TIMELIMIT parameter specifies the amount of time, in sec‐
417 onds, to wait while trying to connect to an LDAP server. If multi‐
418 ple URIs or HOSTs are specified, this is the amount of time to wait
419 before trying the next one in the list.
420 BINDDN DN
422 The BINDDN parameter specifies the identity, in the form of a Dis‐
423 tinguished Name (DN), to use when performing LDAP operations. If
424 not specified, LDAP operations are performed with an anonymous
425 identity. By default, most LDAP servers will allow anonymous
426 access.
427 BINDPW secret
429 The BINDPW parameter specifies the password to use when performing
430 LDAP operations. This is typically used in conjunction with the
431 BINDDN parameter. The secret may be a plain text password or a
432 base64-encoded string with a “base64:” prefix. For example:
433 BINDPW base64:dGVzdA==
435 If a plain text password is used, it should be a simple string
437 without quotes. Plain text passwords may not include the comment
438 character (‘#’) and the escaping of special characters with a back‐
439 slash (‘\’) is not supported.
440 DEREF never/searching/finding/always
442 How alias dereferencing is to be performed when searching. See the
443 ldap.conf(5) manual for a full description of this option.
444 HOST name[:port] ...
446 If no URI is specified (see below), the HOST parameter specifies a
447 white space-delimited list of LDAP servers to connect to. Each
448 host may include an optional port separated by a colon (‘:’). The
449 HOST parameter is deprecated in favor of the URI specification and
450 is included for backwards compatibility only.
451 KRB5_CCNAME file name
453 The path to the Kerberos 5 credential cache to use when authenti‐
454 cating with the remote server. This option is only relevant when
455 using SASL authentication (see below).
456 LDAP_VERSION number
458 The version of the LDAP protocol to use when connecting to the
459 server. The default value is protocol version 3.
460 NETGROUP_BASE base
462 The base DN to use when performing LDAP netgroup queries. Typi‐
463 cally this is of the form ou=netgroup,dc=my-domain,dc=com for the
464 domain my-domain.com. Multiple NETGROUP_BASE lines may be speci‐
465 fied, in which case they are queried in the order specified.
466 This option can be used to query a user's netgroups directly via
468 LDAP which is usually faster than fetching every sudoRole object
469 containing a sudoUser that begins with a ‘+’ prefix. The NIS
470 schema used by some LDAP servers need a modification to support
471 querying the nisNetgroup object by its nisNetgroupTriple member.
472 OpenLDAP's slapd requires the following change to the
473 nisNetgroupTriple attribute:
474 attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
476 DESC 'Netgroup triple'
477 EQUALITY caseIgnoreIA5Match
478 SUBSTR caseIgnoreIA5SubstringsMatch
479 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
480 NETGROUP_SEARCH_FILTER ldap_filter
482 An LDAP filter which is used to restrict the set of records
483 returned when performing an LDAP netgroup query. Typically, this
484 is of the form attribute=value or
485 (&(attribute=value)(attribute2=value2)). The default search filter
486 is: objectClass=nisNetgroup. If ldap_filter is omitted, no search
487 filter will be used. This option is only when querying netgroups
488 directly via LDAP.
489 NETWORK_TIMEOUT seconds
491 An alias for BIND_TIMELIMIT provided for OpenLDAP compatibility.
492 PORT port_number
494 If no URI is specified, the PORT parameter specifies the default
495 port to connect to on the LDAP server if a HOST parameter does not
496 specify the port itself. If no PORT parameter is used, the default
497 is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
498 PORT parameter is deprecated in favor of the URI specification and
499 is included for backwards compatibility only.
500 ROOTBINDDN DN
502 The ROOTBINDDN parameter specifies the identity, in the form of a
503 Distinguished Name (DN), to use when performing privileged LDAP
504 operations, such as sudoers queries. The password corresponding to
505 the identity should be stored in the or the path specified by the
506 ldap_secret plugin argument in sudo.conf(5), which defaults to
507 /etc/ldap.secret. If no ROOTBINDDN is specified, the BINDDN iden‐
508 tity is used (if any).
509 ROOTUSE_SASL on/true/yes/off/false/no
511 Enable ROOTUSE_SASL to enable SASL authentication when connecting
512 to an LDAP server from a privileged process, such as sudo.
513 SASL_AUTH_ID identity
515 The SASL user name to use when connecting to the LDAP server. By
516 default, sudo will use an anonymous connection. This option is
517 only relevant when using SASL authentication.
518 SASL_MECH mechanisms
520 A white space-delimited list of SASL authentication mechanisms to
521 use. By default, sudo will use GSSAPI authentication.
522 SASL_SECPROPS none/properties
524 SASL security properties or none for no properties. See the SASL
525 programmer's manual for details. This option is only relevant when
526 using SASL authentication.
527 SSL on/true/yes/off/false/no
529 If the SSL parameter is set to on, true or yes, TLS (SSL) encryp‐
530 tion is always used when communicating with the LDAP server. Typi‐
531 cally, this involves connecting to the server on port 636 (ldaps).
532 SSL start_tls
534 If the SSL parameter is set to start_tls, the LDAP server connec‐
535 tion is initiated normally and TLS encryption is begun before the
536 bind credentials are sent. This has the advantage of not requiring
537 a dedicated port for encrypted communications. This parameter is
538 only supported by LDAP servers that honor the start_tls extension,
539 such as the OpenLDAP and Tivoli Directory servers.
540 SUDOERS_BASE base
542 The base DN to use when performing sudo LDAP queries. Typically
543 this is of the form ou=SUDOers,dc=my-domain,dc=com for the domain
544 my-domain.com. Multiple SUDOERS_BASE lines may be specified, in
545 which case they are queried in the order specified.
546 SUDOERS_DEBUG debug_level
548 This sets the debug level for sudo LDAP queries. Debugging infor‐
549 mation is printed to the standard error. A value of 1 results in a
550 moderate amount of debugging information. A value of 2 shows the
551 results of the matches themselves. This parameter should not be
552 set in a production environment as the extra information is likely
553 to confuse users.
554 The SUDOERS_DEBUG parameter is deprecated and will be removed in a
556 future release. The same information is now logged via the sudo
557 debugging framework using the “ldap” subsystem at priorities diag
558 and info for debug_level values 1 and 2 respectively. See the
559 sudo.conf(5) manual for details on how to configure sudo debugging.
560 SUDOERS_SEARCH_FILTER ldap_filter
562 An LDAP filter which is used to restrict the set of records
563 returned when performing a sudo LDAP query. Typically, this is of
564 the form attribute=value or
565 (&(attribute=value)(attribute2=value2)). The default search filter
566 is: objectClass=sudoRole. If ldap_filter is omitted, no search
567 filter will be used.
568 SUDOERS_TIMED on/true/yes/off/false/no
570 Whether or not to evaluate the sudoNotBefore and sudoNotAfter
571 attributes that implement time-dependent sudoers entries.
572 TIMELIMIT seconds
574 The TIMELIMIT parameter specifies the amount of time, in seconds,
575 to wait for a response to an LDAP query.
576 TIMEOUT seconds
578 The TIMEOUT parameter specifies the amount of time, in seconds, to
579 wait for a response from the various LDAP APIs.
580 TLS_CACERT file name
582 An alias for TLS_CACERTFILE for OpenLDAP compatibility.
583 TLS_CACERTFILE file name
585 The path to a certificate authority bundle which contains the cer‐
586 tificates for all the Certificate Authorities the client knows to
587 be valid, e.g., /etc/ssl/ca-bundle.pem. This option is only sup‐
588 ported by the OpenLDAP libraries. Netscape-derived LDAP libraries
589 use the same certificate database for CA and client certificates
590 (see TLS_CERT).
591 TLS_CACERTDIR directory
593 Similar to TLS_CACERTFILE but instead of a file, it is a directory
594 containing individual Certificate Authority certificates, e.g.,
595 /etc/ssl/certs. The directory specified by TLS_CACERTDIR is
596 checked after TLS_CACERTFILE. This option is only supported by the
597 OpenLDAP libraries.
598 TLS_CERT file name
600 The path to a file containing the client certificate which can be
601 used to authenticate the client to the LDAP server. The certifi‐
602 cate type depends on the LDAP libraries used.
603 OpenLDAP:
605 tls_cert /etc/ssl/client_cert.pem
606 Netscape-derived:
608 tls_cert /var/ldap/cert7.db
609 Tivoli Directory Server:
611 Unused, the key database specified by TLS_KEY contains both
612 keys and certificates.
613 When using Netscape-derived libraries, this file may also
615 contain Certificate Authority certificates.
616 TLS_CHECKPEER on/true/yes/off/false/no
618 If enabled, TLS_CHECKPEER will cause the LDAP server's TLS certifi‐
619 cated to be verified. If the server's TLS certificate cannot be
620 verified (usually because it is signed by an unknown certificate
621 authority), sudo will be unable to connect to it. If TLS_CHECKPEER
622 is disabled, no check is made. Note that disabling the check cre‐
623 ates an opportunity for man-in-the-middle attacks since the
624 server's identity will not be authenticated. If possible, the CA's
625 certificate should be installed locally so it can be verified.
626 This option is not supported by the Tivoli Directory Server LDAP
627 libraries.
628 TLS_KEY file name
630 The path to a file containing the private key which matches the
631 certificate specified by TLS_CERT. The private key must not be
632 password-protected. The key type depends on the LDAP libraries
633 used.
634 OpenLDAP:
636 tls_key /etc/ssl/client_key.pem
637 Netscape-derived:
639 tls_key /var/ldap/key3.db
640 Tivoli Directory Server:
642 tls_key /usr/ldap/ldapkey.kdb
643 When using Tivoli LDAP libraries, this file may also contain Cer‐
644 tificate Authority and client certificates and may be encrypted.
645 TLS_CIPHERS cipher list
647 The TLS_CIPHERS parameter allows the administer to restrict which
648 encryption algorithms may be used for TLS (SSL) connections. See
649 the OpenLDAP or Tivoli Directory Server manual for a list of valid
650 ciphers. This option is not supported by Netscape-derived
651 libraries.
652 TLS_KEYPW secret
654 The TLS_KEYPW contains the password used to decrypt the key data‐
655 base on clients using the Tivoli Directory Server LDAP library.
656 The secret may be a plain text password or a base64-encoded string
657 with a “base64:” prefix. For example:
658 TLS_KEYPW base64:dGVzdA==
660 If a plain text password is used, it should be a simple string
662 without quotes. Plain text passwords may not include the comment
663 character (‘#’) and the escaping of special characters with a back‐
664 slash (‘\’) is not supported. If this option is used,
665 /etc/ldap.conf must not be world-readable to avoid exposing the
666 password. Alternately, a stash file can be used to store the pass‐
667 word in encrypted form (see below).
668 If no TLS_KEYPW is specified, a stash file will be used if it
670 exists. The stash file must have the same path as the file speci‐
671 fied by TLS_KEY, but use a .sth file extension instead of .kdb,
672 e.g., ldapkey.sth. The default ldapkey.kdb that ships with Tivoli
673 Directory Server is encrypted with the password ssl_password. The
674 gsk8capicmd utility can be used to manage the key database and cre‐
675 ate a stash file. This option is only supported by the Tivoli LDAP
676 libraries.
677 TLS_REQCERT level
679 The TLS_REQCERT parameter controls how the LDAP server's TLS cer‐
680 tificated will be verified (if at all). If the server's TLS cer‐
681 tificate cannot be verified (usually because it is signed by an
682 unknown certificate authority), sudo will be unable to connect to
683 it. The following level values are supported:
684 never The server certificate will not be requested or
686 checked.
687 allow The server certificate will be requested. A missing
689 or invalid certificate is ignored and not considered
690 an error.
691 try The server certificate will be requested. A missing
693 certificate is ignored but an invalid certificate
694 will result in a connection error.
695 demand | hard
697 The server certificate will be requested. A missing
698 or invalid certificate will result in a connection
699 error. This is the default behavior.
700 This option is only supported by the OpenLDAP libraries. Other
702 LDAP libraries only support the TLS_CHECKPEER parameter.
703 TLS_RANDFILE file name
705 The TLS_RANDFILE parameter specifies the path to an entropy source
706 for systems that lack a random device. It is generally used in
707 conjunction with prngd or egd. This option is only supported by
708 the OpenLDAP libraries.
709 URI ldap[s]://[hostname[:port]] ...
711 Specifies a white space-delimited list of one or more URIs describ‐
712 ing the LDAP server(s) to connect to. The protocol may be either
713 ldap ldaps, the latter being for servers that support TLS (SSL)
714 encryption. If no port is specified, the default is port 389 for
715 ldap:// or port 636 for ldaps://. If no hostname is specified,
716 sudo will connect to localhost. Multiple URI lines are treated
717 identically to a URI line containing multiple entries. Only sys‐
718 tems using the OpenSSL libraries support the mixing of ldap:// and
719 ldaps:// URIs. Both the Netscape-derived and Tivoli LDAP libraries
720 used on most commercial versions of Unix are only capable of sup‐
721 porting one or the other.
722 USE_SASL on/true/yes/off/false/no
724 Enable USE_SASL for LDAP servers that support SASL authentication.
725 ROOTSASL_AUTH_ID identity
727 The SASL user name to use when ROOTUSE_SASL is enabled.
728 See the ldap.conf entry in the EXAMPLES section.
730 Configuring nsswitch.conf
732 Unless it is disabled at build time, sudo consults the Name Service
733 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
734 Sudo looks for a line beginning with sudoers: and uses this to determine
735 the search order. Note that sudo does not stop searching after the first
736 match and later matches take precedence over earlier ones. The following
737 sources are recognized:
738 files read sudoers from /etc/sudoers
740 ldap read sudoers from LDAP
741 In addition, the entry [NOTFOUND=return] will short-circuit the search if
743 the user was not found in the preceding source.
744 To consult LDAP first followed by the local sudoers file (if it exists),
746 use:
747 sudoers: ldap files
749 The local sudoers file can be ignored completely by using:
751 sudoers: ldap
753 If the /etc/nsswitch.conf file is not present or there is no sudoers
755 line, the following default is assumed:
756 sudoers: files
758 Note that /etc/nsswitch.conf is supported even when the underlying oper‐
760 ating system does not use an nsswitch.conf file, except on AIX (see
761 below).
762 Configuring netsvc.conf
764 On AIX systems, the /etc/netsvc.conf file is consulted instead of
765 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
766 nsswitch.conf; information in the previous section unrelated to the file
767 format itself still applies.
768 To consult LDAP first followed by the local sudoers file (if it exists),
770 use:
771 sudoers = ldap, files
773 The local sudoers file can be ignored completely by using:
775 sudoers = ldap
777 To treat LDAP as authoritative and only use the local sudoers file if the
779 user is not present in LDAP, use:
780 sudoers = ldap = auth, files
782 Note that in the above example, the auth qualifier only affects user
784 lookups; both LDAP and sudoers will be queried for Defaults entries.
785 If the /etc/netsvc.conf file is not present or there is no sudoers line,
787 the following default is assumed:
788 sudoers = files
790 Integration with sssd
792 On systems with the System Security Services Daemon (SSSD) and where sudo
793 has been built with SSSD support, it is possible to use SSSD to cache
794 LDAP sudoers rules. To use SSSD as the sudoers source, you should use
795 sss instead of ldap for the sudoers entry in /etc/nsswitch.conf. Note
796 that the /etc/ldap.conf file is not used by the SSSD sudo back end.
797 Please see sssd-sudo(5) for more information on configuring sudo to work
798 with SSSD.
799
801 /etc/ldap.conf LDAP configuration file
802 /etc/nsswitch.conf determines sudoers source order
804 /etc/netsvc.conf determines sudoers source order on AIX
806
808 Example ldap.conf
809 # Either specify one or more URIs or one or more host:port pairs.
810 # If neither is specified sudo will default to localhost, port 389.
811 #
812 #host ldapserver
813 #host ldapserver1 ldapserver2:390
814 #
815 # Default port if host is specified without one, defaults to 389.
816 #port 389
817 #
818 # URI will override the host and port settings.
819 uri ldap://ldapserver
820 #uri ldaps://secureldapserver
821 #uri ldaps://secureldapserver ldap://ldapserver
822 #
823 # The amount of time, in seconds, to wait while trying to connect to
824 # an LDAP server.
825 bind_timelimit 30
826 #
827 # The amount of time, in seconds, to wait while performing an LDAP query.
828 timelimit 30
829 #
830 # Must be set or sudo will ignore LDAP; may be specified multiple times.
831 sudoers_base ou=SUDOers,dc=my-domain,dc=com
832 #
833 # verbose sudoers matching from ldap
834 #sudoers_debug 2
835 #
836 # Enable support for time-based entries in sudoers.
837 #sudoers_timed yes
838 #
839 # optional proxy credentials
840 #binddn <who to search as>
841 #bindpw <password>
842 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
843 #
844 # LDAP protocol version, defaults to 3
845 #ldap_version 3
846 #
847 # Define if you want to use an encrypted LDAP connection.
848 # Typically, you must also set the port to 636 (ldaps).
849 #ssl on
850 #
851 # Define if you want to use port 389 and switch to
852 # encryption before the bind credentials are sent.
853 # Only supported by LDAP servers that support the start_tls
854 # extension such as OpenLDAP.
855 #ssl start_tls
856 #
857 # Additional TLS options follow that allow tweaking of the
858 # SSL/TLS connection.
859 #
860 #tls_checkpeer yes # verify server SSL certificate
861 #tls_checkpeer no # ignore server SSL certificate
862 #
863 # If you enable tls_checkpeer, specify either tls_cacertfile
864 # or tls_cacertdir. Only supported when using OpenLDAP.
865 #
866 #tls_cacertfile /etc/certs/trusted_signers.pem
867 #tls_cacertdir /etc/certs
868 #
869 # For systems that don't have /dev/random
870 # use this along with PRNGD or EGD.pl to seed the
871 # random number pool to generate cryptographic session keys.
872 # Only supported when using OpenLDAP.
873 #
874 #tls_randfile /etc/egd-pool
875 #
876 # You may restrict which ciphers are used. Consult your SSL
877 # documentation for which options go here.
878 # Only supported when using OpenLDAP.
879 #
880 #tls_ciphers <cipher-list>
881 #
882 # Sudo can provide a client certificate when communicating to
883 # the LDAP server.
884 # Tips:
885 # * Enable both lines at the same time.
886 # * Do not password protect the key file.
887 # * Ensure the keyfile is only readable by root.
888 #
889 # For OpenLDAP:
890 #tls_cert /etc/certs/client_cert.pem
891 #tls_key /etc/certs/client_key.pem
892 #
893 # For SunONE or iPlanet LDAP, tls_cert and tls_key may specify either
894 # a directory, in which case the files in the directory must have the
895 # default names (e.g., cert8.db and key4.db), or the path to the cert
896 # and key files themselves. However, a bug in version 5.0 of the LDAP
897 # SDK will prevent specific file names from working. For this reason
898 # it is suggested that tls_cert and tls_key be set to a directory,
899 # not a file name.
900 #
901 # The certificate database specified by tls_cert may contain CA certs
902 # and/or the client's cert. If the client's cert is included, tls_key
903 # should be specified as well.
904 # For backward compatibility, "sslpath" may be used in place of tls_cert.
905 #tls_cert /var/ldap
906 #tls_key /var/ldap
907 #
908 # If using SASL authentication for LDAP (OpenSSL)
909 # use_sasl yes
910 # sasl_auth_id <SASL user name>
911 # rootuse_sasl yes
912 # rootsasl_auth_id <SASL user name for root access>
913 # sasl_secprops none
914 # krb5_ccname /etc/.ldapcache
915 Sudoers schema for OpenLDAP
917 The following schema, in OpenLDAP format, is included with sudo source
918 and binary distributions as schema.OpenLDAP. Simply copy it to the
919 schema directory (e.g., /etc/openldap/schema), add the proper include
920 line in slapd.conf and restart slapd. Sites using the optional on-line
921 configuration supported by OpenLDAP 2.3 and higher should apply the
922 schema.olcSudo file instead.
923 attributetype ( 1.3.6.1.4.1.15953.9.1.1
925 NAME 'sudoUser'
926 DESC 'User(s) who may run sudo'
927 EQUALITY caseExactIA5Match
928 SUBSTR caseExactIA5SubstringsMatch
929 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
930 attributetype ( 1.3.6.1.4.1.15953.9.1.2
932 NAME 'sudoHost'
933 DESC 'Host(s) who may run sudo'
934 EQUALITY caseExactIA5Match
935 SUBSTR caseExactIA5SubstringsMatch
936 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
937 attributetype ( 1.3.6.1.4.1.15953.9.1.3
939 NAME 'sudoCommand'
940 DESC 'Command(s) to be executed by sudo'
941 EQUALITY caseExactIA5Match
942 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
943 attributetype ( 1.3.6.1.4.1.15953.9.1.4
945 NAME 'sudoRunAs'
946 DESC 'User(s) impersonated by sudo'
947 EQUALITY caseExactIA5Match
948 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
949 attributetype ( 1.3.6.1.4.1.15953.9.1.5
951 NAME 'sudoOption'
952 DESC 'Options(s) followed by sudo'
953 EQUALITY caseExactIA5Match
954 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
955 attributetype ( 1.3.6.1.4.1.15953.9.1.6
957 NAME 'sudoRunAsUser'
958 DESC 'User(s) impersonated by sudo'
959 EQUALITY caseExactIA5Match
960 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
961 attributetype ( 1.3.6.1.4.1.15953.9.1.7
963 NAME 'sudoRunAsGroup'
964 DESC 'Group(s) impersonated by sudo'
965 EQUALITY caseExactIA5Match
966 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
967 attributetype ( 1.3.6.1.4.1.15953.9.1.8
969 NAME 'sudoNotBefore'
970 DESC 'Start of time interval for which the entry is valid'
971 EQUALITY generalizedTimeMatch
972 ORDERING generalizedTimeOrderingMatch
973 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
974 attributetype ( 1.3.6.1.4.1.15953.9.1.9
976 NAME 'sudoNotAfter'
977 DESC 'End of time interval for which the entry is valid'
978 EQUALITY generalizedTimeMatch
979 ORDERING generalizedTimeOrderingMatch
980 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
981 attributetype ( 1.3.6.1.4.1.15953.9.1.10
983 NAME 'sudoOrder'
984 DESC 'an integer to order the sudoRole entries'
985 EQUALITY integerMatch
986 ORDERING integerOrderingMatch
987 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
988 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
990 DESC 'Sudoer Entries'
991 MUST ( cn )
992 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
993 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
994 sudoOrder $ description )
995 )
996
998 cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
999
1001 Many people have worked on sudo over the years; this version consists of
1002 code written primarily by:
1003 Todd C. Miller
1005 See the CONTRIBUTORS file in the sudo distribution
1007 (https://www.sudo.ws/contributors.html) for an exhaustive list of people
1008 who have contributed to sudo.
1009
1011 Note that there are differences in the way that LDAP-based sudoers is
1012 parsed compared to file-based sudoers. See the Differences between LDAP
1013 and non-LDAP sudoers section for more information.
1014
1016 If you feel you have found a bug in sudo, please submit a bug report at
1017 https://bugzilla.sudo.ws/
1018
1020 Limited free support is available via the sudo-users mailing list, see
1021 https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
1022 the archives.
1023
1025 sudo is provided “AS IS” and any express or implied warranties, includ‐
1026 ing, but not limited to, the implied warranties of merchantability and
1027 fitness for a particular purpose are disclaimed. See the LICENSE file
1028 distributed with sudo or https://www.sudo.ws/license.html for complete
1029 details.
1030Sudo 1.8.29 October 20, 2019 Sudo 1.8.29