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
11 Using LDAP for sudoers has several benefits:
12
13 • 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
17 • 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
23 • 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
29 SUDOers LDAP container
30 The sudoers configuration is contained in the ‘ou=SUDOers’ LDAP con‐
31 tainer.
32
33 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
39 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
46 The equivalent of a sudoer in LDAP is a sudoRole. It consists of the
47 following attributes:
48
49 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
62 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
72 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
78 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
84 The special value ALL will match any command.
85
86 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
95 sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
96
97 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
101 sudoOption
102 Identical in function to the global options described above, but
103 specific to the sudoRole in which it resides.
104
105 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
116 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
121 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
128 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
132 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
141 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
145 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
154 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
158 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
169 The sudoOrder attribute is only available in sudo versions 1.7.5
170 and higher.
171
172 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
176 The following example allows users in group wheel to run any command on
177 any host via sudo:
178
179 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
187 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
196 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
200 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
208 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
218 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
222 For sites with a large number of netgroups, using NETGROUP_BASE can sig‐
223 nificantly speed up sudo's execution time.
224
225 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
229 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
235 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
240 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
246 Here is an example:
247
248 # /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
254 # 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
265 # 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
277 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
283 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
287 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
291 Consider the following sudoers lines:
292
293 Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less
294 Defaults!PAGERS noexec
295 alice, bob ALL = ALL
296
297 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
301 When converting this to LDAP, two sudoRole objects can be used:
302
303 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
316 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
326 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
333 Per-user Defaults entries can be emulated by using one or more sudoOption
334 attributes in a sudoRole. Consider the following sudoers lines:
335
336 User_Alias ADMINS = john, sally
337 Defaults:ADMINS !authenticate
338 ADMINS ALL = (ALL:ALL) ALL
339
340 In this example, john and sally are allowed to run any command as any
341 user or group.
342
343 When converting this to LDAP, we can use a Unix group instead of the
344 User_Alias.
345
346 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
357 This assumes that users john and sally are members of the “admins” Unix
358 group.
359
360 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
364 The sudo distribution includes versions of the sudoers schema for multi‐
365 ple LDAP servers:
366
367 schema.OpenLDAP
368 OpenLDAP slapd and OpenBSD ldapd
369
370 schema.olcSudo
371 OpenLDAP slapd 2.3 and higher when on-line configuration is enabled
372
373 schema.iPlanet
374 Netscape-derived servers such as the iPlanet, Oracle, and 389 Di‐
375 rectory Servers
376
377 schema.ActiveDirectory
378 Microsoft Active Directory
379
380 The schema in OpenLDAP format is also included in the EXAMPLES section.
381
382 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
390 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
393 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
399 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
403 Lines beginning with a pound sign (‘#’) are ignored. Leading white space
404 is removed from the beginning of lines.
405
406 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
412 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
419 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
425 BINDPW base64:dGVzdA==
426
427 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
432 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
436 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
443 KRB5_CCNAME file name
444 The path to the Kerberos 5 credential cache to use when authenti‐
445 cating with the remote server.
446
447 This option is only relevant when using SASL authentication (see
448 below).
449
450 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
454 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
460 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
468 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
474 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
482 This option is only used when querying netgroups directly via LDAP.
483
484 NETWORK_TIMEOUT seconds
485 An alias for BIND_TIMELIMIT provided for OpenLDAP compatibility.
486
487 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
495 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
504 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
508 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
512 This option is only relevant when using SASL authentication.
513
514 SASL_MECH mechanisms
515 A white space-delimited list of SASL authentication mechanisms to
516 use. By default, sudo will use GSSAPI authentication.
517
518 SASL_SECPROPS none/properties
519 SASL security properties or none for no properties. See the SASL
520 programmer's manual for details.
521
522 This option is only relevant when using SASL authentication.
523
524 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
529 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
537 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
543 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
551 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
557 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
565 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
569 TIMELIMIT seconds
570 The TIMELIMIT parameter specifies the amount of time, in seconds,
571 to wait for a response to an LDAP query.
572
573 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
577 TLS_CACERT file name
578 An alias for TLS_CACERTFILE for OpenLDAP compatibility.
579
580 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
585 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
589 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
595 This option is only supported by the OpenLDAP libraries.
596
597 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
602 OpenLDAP:
603 ‘tls_cert /etc/ssl/client_cert.pem’
604
605 Netscape-derived:
606 ‘tls_cert /var/ldap/cert7.db’
607
608 IBM LDAP:
609 Unused, the key database specified by TLS_KEY contains both
610 keys and certificates.
611
612 When using Netscape-derived libraries, this file may also contain
613 Certificate Authority certificates.
614
615 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
625 This option is not supported by the IBM LDAP libraries.
626
627 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
633 OpenLDAP:
634 ‘tls_key /etc/ssl/client_key.pem’
635
636 Netscape-derived:
637 ‘tls_key /var/ldap/key3.db’
638
639 IBM LDAP:
640 ‘tls_key /usr/ldap/ldapkey.kdb’
641
642 When using IBM LDAP libraries, this file may also contain Certifi‐
643 cate Authority and client certificates and may be encrypted.
644
645 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
651 This option is not supported by Netscape-derived libraries.
652
653 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
659 TLS_KEYPW base64:dGVzdA==
660
661 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
669 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
677 This option is only supported by the IBM LDAP libraries.
678
679 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
686 never
687 The server certificate will not be requested or checked.
688
689 allow
690 The server certificate will be requested. A missing or
691 invalid certificate is ignored and not considered an er‐
692 ror.
693
694 try The server certificate will be requested. A missing cer‐
695 tificate is ignored but an invalid certificate will re‐
696 sult in a connection error.
697
698 demand | hard
699 The server certificate will be requested. A missing or
700 invalid certificate will result in a connection error.
701 This is the default behavior.
702
703 This option is only supported by the OpenLDAP libraries. Other
704 LDAP libraries only support the TLS_CHECKPEER parameter.
705
706 TLS_RANDFILE file name
707 The TLS_RANDFILE parameter specifies the path to an entropy source
708 for systems that lack a random device. It is generally used in
709 conjunction with prngd or egd.
710
711 This option is only supported by the OpenLDAP libraries.
712
713 URI ldap[s]://[hostname[:port]] ...
714 Specifies a white space-delimited list of one or more URIs describ‐
715 ing the LDAP server(s) to connect to. The protocol may be either
716 ldap ldaps, the latter being for servers that support TLS (SSL) en‐
717 cryption. If no port is specified, the default is port 389 for
718 ‘ldap://’ or port 636 for ‘ldaps://’. If no hostname is specified,
719 sudo will connect to localhost. Multiple URI lines are treated
720 identically to a URI line containing multiple entries. Only sys‐
721 tems using the OpenSSL libraries support the mixing of ‘ldap://’
722 and ‘ldaps://’ URIs. Both the Netscape-derived and IBM LDAP li‐
723 braries used on most commercial versions of Unix are only capable
724 of supporting one or the other.
725
726 USE_SASL on/true/yes/off/false/no
727 Enable USE_SASL for LDAP servers that support SASL authentication.
728
729 ROOTSASL_AUTH_ID identity
730 The SASL user name to use when ROOTUSE_SASL is enabled.
731
732 See the ldap.conf entry in the EXAMPLES section.
733
734 Configuring nsswitch.conf
735 Unless it is disabled at build time, sudo consults the Name Service
736 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
737 Sudo looks for a line beginning with sudoers: and uses this to determine
738 the search order. By default, sudo does not stop searching after the
739 first match and later matches take precedence over earlier ones (unless
740 ‘[SUCCESS=return]’ is used, see below). The following sources are recog‐
741 nized:
742
743 files read sudoers from /etc/sudoers
744 ldap read sudoers from LDAP
745
746 In addition, a subset of nsswitch.conf-style action statements is sup‐
747 ported, specifically ‘[SUCCESS=return]’ and ‘[NOTFOUND=return]’. These
748 will unconditionally terminate the search if the user was either found
749 ‘[SUCCESS=return]’ or not found ‘[NOTFOUND=return]’ in the immediately
750 preceding source. Other action statements tokens are not supported, nor
751 is test negation with ‘!’.
752
753 To consult LDAP first followed by the local sudoers file (if it exists),
754 use:
755
756 sudoers: ldap files
757
758 To consult LDAP only when no match is found in the local sudoers file (if
759 it exists), use:
760
761 sudoers: files [SUCCESS=return] ldap
762
763 The local sudoers file can be ignored completely by using:
764
765 sudoers: ldap
766
767 If the /etc/nsswitch.conf file is not present or there is no sudoers
768 line, the following default is assumed:
769
770 sudoers: files
771
772 The /etc/nsswitch.conf file is supported even when the underlying operat‐
773 ing system does not support it, except on AIX (see below).
774
775 Configuring netsvc.conf
776 On AIX systems, the /etc/netsvc.conf file is consulted instead of
777 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
778 nsswitch.conf; information in the previous section unrelated to the file
779 format itself still applies.
780
781 To consult LDAP first followed by the local sudoers file (if it exists),
782 use:
783
784 sudoers = ldap, files
785
786 The local sudoers file can be ignored completely by using:
787
788 sudoers = ldap
789
790 To treat LDAP as authoritative and only use the local sudoers file if the
791 user is not present in LDAP, use:
792
793 sudoers = ldap = auth, files
794
795 In the above example, the auth qualifier only affects user lookups; both
796 LDAP and sudoers will be queried for Defaults entries.
797
798 If the /etc/netsvc.conf file is not present or there is no sudoers line,
799 the following default is assumed:
800
801 sudoers = files
802
803 Integration with sssd
804 On systems with the System Security Services Daemon (SSSD) and where sudo
805 has been built with SSSD support, it is possible to use SSSD to cache
806 LDAP sudoers rules. To use SSSD as the sudoers source, you should use
807 sss instead of ldap for the sudoers entry in /etc/nsswitch.conf. The
808 /etc/ldap.conf file is not used by the SSSD sudo back end. See
809 sssd-sudo(5) for more information on configuring sudo to work with SSSD.
810
812 /etc/ldap.conf LDAP configuration file
813
814 /etc/nsswitch.conf determines sudoers source order
815
816 /etc/netsvc.conf determines sudoers source order on AIX
817
819 Example ldap.conf
820 # Either specify one or more URIs or one or more host:port pairs.
821 # If neither is specified sudo will default to localhost, port 389.
822 #
823 #host ldapserver
824 #host ldapserver1 ldapserver2:390
825 #
826 # Default port if host is specified without one, defaults to 389.
827 #port 389
828 #
829 # URI will override the host and port settings.
830 uri ldap://ldapserver
831 #uri ldaps://secureldapserver
832 #uri ldaps://secureldapserver ldap://ldapserver
833 #
834 # The amount of time, in seconds, to wait while trying to connect to
835 # an LDAP server.
836 bind_timelimit 30
837 #
838 # The amount of time, in seconds, to wait while performing an LDAP query.
839 timelimit 30
840 #
841 # Must be set or sudo will ignore LDAP; may be specified multiple times.
842 sudoers_base ou=SUDOers,dc=my-domain,dc=com
843 #
844 # verbose sudoers matching from ldap
845 #sudoers_debug 2
846 #
847 # Enable support for time-based entries in sudoers.
848 #sudoers_timed yes
849 #
850 # optional proxy credentials
851 #binddn <who to search as>
852 #bindpw <password>
853 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
854 #
855 # LDAP protocol version, defaults to 3
856 #ldap_version 3
857 #
858 # Define if you want to use an encrypted LDAP connection.
859 # Typically, you must also set the port to 636 (ldaps).
860 #ssl on
861 #
862 # Define if you want to use port 389 and switch to
863 # encryption before the bind credentials are sent.
864 # Only supported by LDAP servers that support the start_tls
865 # extension such as OpenLDAP.
866 #ssl start_tls
867 #
868 # Additional TLS options follow that allow tweaking of the
869 # SSL/TLS connection.
870 #
871 #tls_checkpeer yes # verify server SSL certificate
872 #tls_checkpeer no # ignore server SSL certificate
873 #
874 # If you enable tls_checkpeer, specify either tls_cacertfile
875 # or tls_cacertdir. Only supported when using OpenLDAP.
876 #
877 #tls_cacertfile /etc/certs/trusted_signers.pem
878 #tls_cacertdir /etc/certs
879 #
880 # For systems that don't have /dev/random
881 # use this along with PRNGD or EGD.pl to seed the
882 # random number pool to generate cryptographic session keys.
883 # Only supported when using OpenLDAP.
884 #
885 #tls_randfile /etc/egd-pool
886 #
887 # You may restrict which ciphers are used. Consult your SSL
888 # documentation for which options go here.
889 # Only supported when using OpenLDAP.
890 #
891 #tls_ciphers <cipher-list>
892 #
893 # Sudo can provide a client certificate when communicating to
894 # the LDAP server.
895 # Tips:
896 # * Enable both lines at the same time.
897 # * Do not password protect the key file.
898 # * Ensure the keyfile is only readable by root.
899 #
900 # For OpenLDAP:
901 #tls_cert /etc/certs/client_cert.pem
902 #tls_key /etc/certs/client_key.pem
903 #
904 # For Netscape-derived LDAP, tls_cert and tls_key may specify either
905 # a directory, in which case the files in the directory must have the
906 # default names (e.g., cert8.db and key4.db), or the path to the cert
907 # and key files themselves. However, a bug in version 5.0 of the LDAP
908 # SDK will prevent specific file names from working. For this reason
909 # it is suggested that tls_cert and tls_key be set to a directory,
910 # not a file name.
911 #
912 # The certificate database specified by tls_cert may contain CA certs
913 # and/or the client's cert. If the client's cert is included, tls_key
914 # should be specified as well.
915 # For backward compatibility, "sslpath" may be used in place of tls_cert.
916 #tls_cert /var/ldap
917 #tls_key /var/ldap
918 #
919 # If using SASL authentication for LDAP (OpenSSL)
920 # use_sasl yes
921 # sasl_auth_id <SASL user name>
922 # rootuse_sasl yes
923 # rootsasl_auth_id <SASL user name for root access>
924 # sasl_secprops none
925 # krb5_ccname /etc/.ldapcache
926
927 Sudoers schema for OpenLDAP
928 The following schema, in OpenLDAP format, is included with sudo source
929 and binary distributions as schema.OpenLDAP. Simply copy it to the
930 schema directory (e.g., /etc/openldap/schema), add the proper include
931 line in slapd.conf and restart slapd. Sites using the optional on-line
932 configuration supported by OpenLDAP 2.3 and higher should apply the
933 schema.olcSudo file instead.
934
935 attributetype ( 1.3.6.1.4.1.15953.9.1.1
936 NAME 'sudoUser'
937 DESC 'User(s) who may run sudo'
938 EQUALITY caseExactMatch
939 SUBSTR caseExactSubstringsMatch
940 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
941
942 attributetype ( 1.3.6.1.4.1.15953.9.1.2
943 NAME 'sudoHost'
944 DESC 'Host(s) who may run sudo'
945 EQUALITY caseExactIA5Match
946 SUBSTR caseExactIA5SubstringsMatch
947 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
948
949 attributetype ( 1.3.6.1.4.1.15953.9.1.3
950 NAME 'sudoCommand'
951 DESC 'Command(s) to be executed by sudo'
952 EQUALITY caseExactIA5Match
953 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
954
955 attributetype ( 1.3.6.1.4.1.15953.9.1.4
956 NAME 'sudoRunAs'
957 DESC 'User(s) impersonated by sudo'
958 EQUALITY caseExactIA5Match
959 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
960
961 attributetype ( 1.3.6.1.4.1.15953.9.1.5
962 NAME 'sudoOption'
963 DESC 'Options(s) followed by sudo'
964 EQUALITY caseExactIA5Match
965 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
966
967 attributetype ( 1.3.6.1.4.1.15953.9.1.6
968 NAME 'sudoRunAsUser'
969 DESC 'User(s) impersonated by sudo'
970 EQUALITY caseExactMatch
971 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
972
973 attributetype ( 1.3.6.1.4.1.15953.9.1.7
974 NAME 'sudoRunAsGroup'
975 DESC 'Group(s) impersonated by sudo'
976 EQUALITY caseExactMatch
977 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
978
979 attributetype ( 1.3.6.1.4.1.15953.9.1.8
980 NAME 'sudoNotBefore'
981 DESC 'Start of time interval for which the entry is valid'
982 EQUALITY generalizedTimeMatch
983 ORDERING generalizedTimeOrderingMatch
984 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
985
986 attributetype ( 1.3.6.1.4.1.15953.9.1.9
987 NAME 'sudoNotAfter'
988 DESC 'End of time interval for which the entry is valid'
989 EQUALITY generalizedTimeMatch
990 ORDERING generalizedTimeOrderingMatch
991 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
992
993 attributetype ( 1.3.6.1.4.1.15953.9.1.10
994 NAME 'sudoOrder'
995 DESC 'an integer to order the sudoRole entries'
996 EQUALITY integerMatch
997 ORDERING integerOrderingMatch
998 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
999
1000 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
1001 DESC 'Sudoer Entries'
1002 MUST ( cn )
1003 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
1004 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
1005 sudoOrder $ description )
1006 )
1007
1009 cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
1010
1012 Many people have worked on sudo over the years; this version consists of
1013 code written primarily by:
1014
1015 Todd C. Miller
1016
1017 See the CONTRIBUTORS.md file in the sudo distribution
1018 (https://www.sudo.ws/about/contributors/) for an exhaustive list of peo‐
1019 ple who have contributed to sudo.
1020
1022 There are differences in the way that LDAP-based sudoers is parsed com‐
1023 pared to file-based sudoers. See the Differences between LDAP and
1024 non-LDAP sudoers section for more information.
1025
1027 If you believe you have found a bug in sudo, you can submit a bug report
1028 at https://bugzilla.sudo.ws/
1029
1031 Limited free support is available via the sudo-users mailing list, see
1032 https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
1033 the archives.
1034
1036 sudo is provided “AS IS” and any express or implied warranties, includ‐
1037 ing, but not limited to, the implied warranties of merchantability and
1038 fitness for a particular purpose are disclaimed. See the LICENSE.md file
1039 distributed with sudo or https://www.sudo.ws/about/license/ for complete
1040 details.
1041
1042Sudo 1.9.13p2 January 16, 2023 Sudo 1.9.13p2