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 environ‐
16 ments.
17 · sudo no longer exits if there is a typo in sudoers. It is not possi‐
19 ble to load LDAP data into the server that does not conform to the
20 sudoers schema, so proper syntax is guaranteed. It is still possible
21 to have typos in a user or host name, but this will not prevent sudo
22 from running.
23 · It is possible to specify per-entry options that override the global
25 default options. /etc/sudoers only supports default options and lim‐
26 ited options associated with user/host/commands/aliases. The syntax
27 is complicated and can be difficult for users to understand. Placing
28 the options directly in the entry is more natural.
29 · The visudo program is no longer needed. visudo provides locking and
31 syntax checking of the /etc/sudoers file. Since LDAP updates are
32 atomic, locking is no longer necessary. Because syntax is checked
33 when the data is inserted into LDAP, there is no need for a special‐
34 ized tool to check syntax.
35 Another major difference between LDAP and file-based sudoers is that in
37 LDAP, sudo-specific Aliases are not supported.
38 For the most part, there is really no need for sudo-specific Aliases.
40 Unix groups or user netgroups can be used in place of User_Aliases and
41 Runas_Aliases. Host netgroups can be used in place of Host_Aliases.
42 Since Unix groups and netgroups can also be stored in LDAP there is no
43 real need for sudo-specific aliases.
44 Cmnd_Aliases are not really required either since it is possible to have
46 multiple users listed in a sudoRole. Instead of defining a Cmnd_Alias
47 that is referenced by multiple users, one can create a sudoRole that con‐
48 tains the commands and assign multiple users to it.
49 SUDOers LDAP container
51 The sudoers configuration is contained in the ou=SUDOers LDAP container.
52 Sudo first looks for the cn=default entry in the SUDOers container. If
54 found, the multi-valued sudoOption attribute is parsed in the same manner
55 as a global Defaults line in /etc/sudoers. In the following example, the
56 SSH_AUTH_SOCK variable will be preserved in the environment for all
57 users.
58 dn: cn=defaults,ou=SUDOers,dc=example,dc=com
60 objectClass: top
61 objectClass: sudoRole
62 cn: defaults
63 description: Default sudoOption's go here
64 sudoOption: env_keep+=SSH_AUTH_SOCK
65 The equivalent of a sudoer in LDAP is a sudoRole. It consists of the
67 following attributes:
68 sudoUser
70 A user name, user ID (prefixed with ‘#’), Unix group (prefixed with
71 ‘%’), Unix group ID (prefixed with ‘%#’), or user netgroup (pre‐
72 fixed with ‘+’).
73 sudoHost
75 A host name, IP address, IP network, or host netgroup (prefixed
76 with a ‘+’). The special value ALL will match any host.
77 sudoCommand
79 A Unix command with optional command line arguments, potentially
80 including globbing characters (aka wild cards). The special value
81 ALL will match any command. If a command is prefixed with an
82 exclamation point ‘!’, the user will be prohibited from running
83 that command.
84 sudoOption
86 Identical in function to the global options described above, but
87 specific to the sudoRole in which it resides.
88 sudoRunAsUser
90 A user name or uid (prefixed with ‘#’) that commands may be run as
91 or a Unix group (prefixed with a ‘%’) or user netgroup (prefixed
92 with a ‘+’) that contains a list of users that commands may be run
93 as. The special value ALL will match any user.
94 The sudoRunAsUser attribute is only available in sudo versions
96 1.7.0 and higher. Older versions of sudo use the sudoRunAs
97 attribute instead.
98 sudoRunAsGroup
100 A Unix group or gid (prefixed with ‘#’) that commands may be run
101 as. The special value ALL will match any group.
102 The sudoRunAsGroup attribute is only available in sudo versions
104 1.7.0 and higher.
105 sudoNotBefore
107 A timestamp in the form yyyymmddHHMMSSZ that can be used to provide
108 a start date/time for when the sudoRole will be valid. If multiple
109 sudoNotBefore entries are present, the earliest is used. Note that
110 timestamps must be in Coordinated Universal Time (UTC), not the
111 local timezone. The minute and seconds portions are optional, but
112 some LDAP servers require that they be present (contrary to the
113 RFC).
114 The sudoNotBefore attribute is only available in sudo versions
116 1.7.5 and higher and must be explicitly enabled via the
117 SUDOERS_TIMED option in /etc/sudo-ldap.conf.
118 sudoNotAfter
120 A timestamp in the form yyyymmddHHMMSSZ that indicates an expira‐
121 tion date/time, after which the sudoRole will no longer be valid.
122 If multiple sudoNotAfter entries are present, the last one is used.
123 Note that timestamps must be in Coordinated Universal Time (UTC),
124 not the local timezone. The minute and seconds portions are
125 optional, but some LDAP servers require that they be present (con‐
126 trary to the RFC).
127 The sudoNotAfter attribute is only available in sudo versions 1.7.5
129 and higher and must be explicitly enabled via the SUDOERS_TIMED
130 option in /etc/sudo-ldap.conf.
131 sudoOrder
133 The sudoRole entries retrieved from the LDAP directory have no
134 inherent order. The sudoOrder attribute is an integer (or floating
135 point value for LDAP servers that support it) that is used to sort
136 the matching entries. This allows LDAP-based sudoers entries to
137 more closely mimic the behaviour of the sudoers file, where the
138 order of the entries influences the result. If multiple entries
139 match, the entry with the highest sudoOrder attribute is chosen.
140 This corresponds to the “last match” behavior of the sudoers file.
141 If the sudoOrder attribute is not present, a value of 0 is assumed.
142 The sudoOrder attribute is only available in sudo versions 1.7.5
144 and higher.
145 Each attribute listed above should contain a single value, but there may
147 be multiple instances of each attribute type. A sudoRole must contain at
148 least one sudoUser, sudoHost and sudoCommand.
149 The following example allows users in group wheel to run any command on
151 any host via sudo:
152 dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
154 objectClass: top
155 objectClass: sudoRole
156 cn: %wheel
157 sudoUser: %wheel
158 sudoHost: ALL
159 sudoCommand: ALL
160 Anatomy of LDAP sudoers lookup
162 When looking up a sudoer using LDAP there are only two or three LDAP
163 queries per invocation. The first query is to parse the global options.
164 The second is to match against the user's name and the groups that the
165 user belongs to. (The special ALL tag is matched in this query too.) If
166 no match is returned for the user's name and groups, a third query
167 returns all entries containing user netgroups and checks to see if the
168 user belongs to any of them.
169 If timed entries are enabled with the SUDOERS_TIMED configuration direc‐
171 tive, the LDAP queries include a subfilter that limits retrieval to
172 entries that satisfy the time constraints, if any.
173 Differences between LDAP and non-LDAP sudoers
175 There are some subtle differences in the way sudoers is handled once in
176 LDAP. Probably the biggest is that according to the RFC, LDAP ordering
177 is arbitrary and you cannot expect that Attributes and Entries are
178 returned in any specific order.
179 The order in which different entries are applied can be controlled using
181 the sudoOrder attribute, but there is no way to guarantee the order of
182 attributes within a specific entry. If there are conflicting command
183 rules in an entry, the negative takes precedence. This is called para‐
184 noid behavior (not necessarily the most specific match).
185 Here is an example:
187 # /etc/sudoers:
189 # Allow all commands except shell
190 johnny ALL=(root) ALL,!/bin/sh
191 # Always allows all commands because ALL is matched last
192 puddles ALL=(root) !/bin/sh,ALL
193 # LDAP equivalent of johnny
195 # Allows all commands except shell
196 dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
197 objectClass: sudoRole
198 objectClass: top
199 cn: role1
200 sudoUser: johnny
201 sudoHost: ALL
202 sudoCommand: ALL
203 sudoCommand: !/bin/sh
204 # LDAP equivalent of puddles
206 # Notice that even though ALL comes last, it still behaves like
207 # role1 since the LDAP code assumes the more paranoid configuration
208 dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
209 objectClass: sudoRole
210 objectClass: top
211 cn: role2
212 sudoUser: puddles
213 sudoHost: ALL
214 sudoCommand: !/bin/sh
215 sudoCommand: ALL
216 Another difference is that negations on the Host, User or Runas are cur‐
218 rently ignored. For example, the following attributes do not behave the
219 way one might expect.
220 # does not match all but joe
222 # rather, does not match anyone
223 sudoUser: !joe
224 # does not match all but joe
226 # rather, matches everyone including Joe
227 sudoUser: ALL
228 sudoUser: !joe
229 # does not match all but web01
231 # rather, matches all hosts including web01
232 sudoHost: ALL
233 sudoHost: !web01
234 Sudoers schema
236 In order to use sudo's LDAP support, the sudo schema must be installed on
237 your LDAP server. In addition, be sure to index the sudoUser attribute.
238 Three versions of the schema: one for OpenLDAP servers (schema.OpenLDAP),
240 one for Netscape-derived servers (schema.iPlanet), and one for Microsoft
241 Active Directory (schema.ActiveDirectory) may be found in the sudo dis‐
242 tribution.
243 The schema for sudo in OpenLDAP form is also included in the EXAMPLES
245 section.
246 Configuring ldap.conf
248 Sudo reads the /etc/sudo-ldap.conf file for LDAP-specific configuration.
249 Typically, this file is shared amongst different LDAP-aware clients. As
250 such, most of the settings are not sudo-specific. Note that sudo parses
251 /etc/sudo-ldap.conf itself and may support options that differ from those
252 described in the system's ldap.conf(8) manual.
253 Also note that on systems using the OpenLDAP libraries, default values
255 specified in /etc/openldap/ldap.conf or the user's .ldaprc files are not
256 used.
257 Only those options explicitly listed in /etc/sudo-ldap.conf as being sup‐
259 ported by sudo are honored. Configuration options are listed below in
260 upper case but are parsed in a case-independent manner.
261 URI ldap[s]://[hostname[:port]] ...
263 Specifies a whitespace-delimited list of one or more URIs describ‐
264 ing the LDAP server(s) to connect to. The protocol may be either
265 ldap ldaps, the latter being for servers that support TLS (SSL)
266 encryption. If no port is specified, the default is port 389 for
267 ldap:// or port 636 for ldaps://. If no hostname is specified,
268 sudo will connect to localhost. Multiple URI lines are treated
269 identically to a URI line containing multiple entries. Only sys‐
270 tems using the OpenSSL libraries support the mixing of ldap:// and
271 ldaps:// URIs. Both the Netscape-derived and Tivoli LDAP libraries
272 used on most commercial versions of Unix are only capable of sup‐
273 porting one or the other.
274 HOST name[:port] ...
276 If no URI is specified, the HOST parameter specifies a whitespace-
277 delimited list of LDAP servers to connect to. Each host may
278 include an optional port separated by a colon (‘:’). The HOST
279 parameter is deprecated in favor of the URI specification and is
280 included for backwards compatibility.
281 PORT port_number
283 If no URI is specified, the PORT parameter specifies the default
284 port to connect to on the LDAP server if a HOST parameter does not
285 specify the port itself. If no PORT parameter is used, the default
286 is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
287 PORT parameter is deprecated in favor of the URI specification and
288 is included for backwards compatibility.
289 BIND_TIMELIMIT seconds
291 The BIND_TIMELIMIT parameter specifies the amount of time, in sec‐
292 onds, to wait while trying to connect to an LDAP server. If multi‐
293 ple URIs or HOSTs are specified, this is the amount of time to wait
294 before trying the next one in the list.
295 NETWORK_TIMEOUT seconds
297 An alias for BIND_TIMELIMIT for OpenLDAP compatibility.
298 TIMELIMIT seconds
300 The TIMELIMIT parameter specifies the amount of time, in seconds,
301 to wait for a response to an LDAP query.
302 TIMEOUT seconds
304 The TIMEOUT parameter specifies the amount of time, in seconds, to
305 wait for a response from the various LDAP APIs.
306 SUDOERS_BASE base
308 The base DN to use when performing sudo LDAP queries. Typically
309 this is of the form ou=SUDOers,dc=example,dc=com for the domain
310 example.com. Multiple SUDOERS_BASE lines may be specified, in
311 which case they are queried in the order specified.
312 SUDOERS_SEARCH_FILTER ldap_filter
314 An LDAP filter which is used to restrict the set of records
315 returned when performing a sudo LDAP query. Typically, this is of
316 the form attribute=value or
317 (&(attribute=value)(attribute2=value2)).
318 SUDOERS_TIMED on/true/yes/off/false/no
320 Whether or not to evaluate the sudoNotBefore and sudoNotAfter
321 attributes that implement time-dependent sudoers entries.
322 SUDOERS_DEBUG debug_level
324 This sets the debug level for sudo LDAP queries. Debugging infor‐
325 mation is printed to the standard error. A value of 1 results in a
326 moderate amount of debugging information. A value of 2 shows the
327 results of the matches themselves. This parameter should not be
328 set in a production environment as the extra information is likely
329 to confuse users.
330 BINDDN DN
332 The BINDDN parameter specifies the identity, in the form of a Dis‐
333 tinguished Name (DN), to use when performing LDAP operations. If
334 not specified, LDAP operations are performed with an anonymous
335 identity. By default, most LDAP servers will allow anonymous
336 access.
337 BINDPW secret
339 The BINDPW parameter specifies the password to use when performing
340 LDAP operations. This is typically used in conjunction with the
341 BINDDN parameter.
342 ROOTBINDDN DN
344 The ROOTBINDDN parameter specifies the identity, in the form of a
345 Distinguished Name (DN), to use when performing privileged LDAP
346 operations, such as sudoers queries. The password corresponding to
347 the identity should be stored in /etc/ldap.secret. If not speci‐
348 fied, the BINDDN identity is used (if any).
349 LDAP_VERSION number
351 The version of the LDAP protocol to use when connecting to the
352 server. The default value is protocol version 3.
353 SSL on/true/yes/off/false/no
355 If the SSL parameter is set to on, true or yes, TLS (SSL) encryp‐
356 tion is always used when communicating with the LDAP server. Typi‐
357 cally, this involves connecting to the server on port 636 (ldaps).
358 SSL start_tls
360 If the SSL parameter is set to start_tls, the LDAP server connec‐
361 tion is initiated normally and TLS encryption is begun before the
362 bind credentials are sent. This has the advantage of not requiring
363 a dedicated port for encrypted communications. This parameter is
364 only supported by LDAP servers that honor the start_tls extension,
365 such as the OpenLDAP and Tivoli Directory servers.
366 TLS_CHECKPEER on/true/yes/off/false/no
368 If enabled, TLS_CHECKPEER will cause the LDAP server's TLS certifi‐
369 cated to be verified. If the server's TLS certificate cannot be
370 verified (usually because it is signed by an unknown certificate
371 authority), sudo will be unable to connect to it. If TLS_CHECKPEER
372 is disabled, no check is made. Note that disabling the check cre‐
373 ates an opportunity for man-in-the-middle attacks since the
374 server's identity will not be authenticated. If possible, the CA's
375 certificate should be installed locally so it can be verified.
376 This option is not supported by the Tivoli Directory Server LDAP
377 libraries.
378 TLS_CACERT file name
380 An alias for TLS_CACERTFILE for OpenLDAP compatibility.
381 TLS_CACERTFILE file name
383 The path to a certificate authority bundle which contains the cer‐
384 tificates for all the Certificate Authorities the client knows to
385 be valid, e.g. /etc/ssl/ca-bundle.pem. This option is only sup‐
386 ported by the OpenLDAP libraries. Netscape-derived LDAP libraries
387 use the same certificate database for CA and client certificates
388 (see TLS_CERT).
389 TLS_CACERTDIR directory
391 Similar to TLS_CACERTFILE but instead of a file, it is a directory
392 containing individual Certificate Authority certificates, e.g.
393 /etc/ssl/certs. The directory specified by TLS_CACERTDIR is
394 checked after TLS_CACERTFILE. This option is only supported by the
395 OpenLDAP libraries.
396 TLS_CERT file name
398 The path to a file containing the client certificate which can be
399 used to authenticate the client to the LDAP server. The certifi‐
400 cate type depends on the LDAP libraries used.
401 OpenLDAP:
403 tls_cert /etc/ssl/client_cert.pem
404 Netscape-derived:
406 tls_cert /var/ldap/cert7.db
407 Tivoli Directory Server:
409 Unused, the key database specified by TLS_KEY contains both
410 keys and certificates.
411 When using Netscape-derived libraries, this file may also
413 contain Certificate Authority certificates.
414 TLS_KEY file name
416 The path to a file containing the private key which matches the
417 certificate specified by TLS_CERT. The private key must not be
418 password-protected. The key type depends on the LDAP libraries
419 used.
420 OpenLDAP:
422 tls_key /etc/ssl/client_key.pem
423 Netscape-derived:
425 tls_key /var/ldap/key3.db
426 Tivoli Directory Server:
428 tls_cert /usr/ldap/ldapkey.kdb
429 When using Tivoli LDAP libraries, this file may also contain Cer‐
430 tificate Authority and client certificates and may be encrypted.
431 TLS_KEYPW secret
433 The TLS_KEYPW contains the password used to decrypt the key data‐
434 base on clients using the Tivoli Directory Server LDAP library. If
435 no TLS_KEYPW is specified, a stash file will be used if it exists.
436 The stash file must have the same path as the file specified by
437 TLS_KEY, but use a .sth file extension instead of .kdb, e.g.
438 ldapkey.sth. The default ldapkey.kdb that ships with Tivoli Direc‐
439 tory Server is encrypted with the password ssl_password. This
440 option is only supported by the Tivoli LDAP libraries.
441 TLS_RANDFILE file name
443 The TLS_RANDFILE parameter specifies the path to an entropy source
444 for systems that lack a random device. It is generally used in
445 conjunction with prngd or egd. This option is only supported by
446 the OpenLDAP libraries.
447 TLS_CIPHERS cipher list
449 The TLS_CIPHERS parameter allows the administer to restrict which
450 encryption algorithms may be used for TLS (SSL) connections. See
451 the OpenLDAP or Tivoli Directory Server manual for a list of valid
452 ciphers. This option is not supported by Netscape-derived
453 libraries.
454 USE_SASL on/true/yes/off/false/no
456 Enable USE_SASL for LDAP servers that support SASL authentication.
457 SASL_AUTH_ID identity
459 The SASL user name to use when connecting to the LDAP server. By
460 default, sudo will use an anonymous connection.
461 ROOTUSE_SASL on/true/yes/off/false/no
463 Enable ROOTUSE_SASL to enable SASL authentication when connecting
464 to an LDAP server from a privileged process, such as sudo.
465 ROOTSASL_AUTH_ID identity
467 The SASL user name to use when ROOTUSE_SASL is enabled.
468 SASL_SECPROPS none/properties
470 SASL security properties or none for no properties. See the SASL
471 programmer's manual for details.
472 KRB5_CCNAME file name
474 The path to the Kerberos 5 credential cache to use when authenti‐
475 cating with the remote server.
476 DEREF never/searching/finding/always
478 How alias dereferencing is to be performed when searching. See the
479 ldap.conf(8) manual for a full description of this option.
480 See the ldap.conf entry in the EXAMPLES section.
482 Configuring nsswitch.conf
484 Unless it is disabled at build time, sudo consults the Name Service
485 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
486 Sudo looks for a line beginning with sudoers: and uses this to determine
487 the search order. Note that sudo does not stop searching after the first
488 match and later matches take precedence over earlier ones. The following
489 sources are recognized:
490 files read sudoers from /etc/sudoers
492 ldap read sudoers from LDAP
493 In addition, the entry [NOTFOUND=return] will short-circuit the search if
495 the user was not found in the preceding source.
496 To consult LDAP first followed by the local sudoers file (if it exists),
498 use:
499 sudoers: ldap files
501 The local sudoers file can be ignored completely by using:
503 sudoers: ldap
505 If the /etc/nsswitch.conf file is not present or there is no sudoers
507 line, the following default is assumed:
508 sudoers: files
510 Note that /etc/nsswitch.conf is supported even when the underlying oper‐
512 ating system does not use an nsswitch.conf file, except on AIX (see
513 below).
514 Configuring netsvc.conf
516 On AIX systems, the /etc/netsvc.conf file is consulted instead of
517 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
518 nsswitch.conf; information in the previous section unrelated to the file
519 format itself still applies.
520 To consult LDAP first followed by the local sudoers file (if it exists),
522 use:
523 sudoers = ldap, files
525 The local sudoers file can be ignored completely by using:
527 sudoers = ldap
529 To treat LDAP as authoratative and only use the local sudoers file if the
531 user is not present in LDAP, use:
532 sudoers = ldap = auth, files
534 Note that in the above example, the auth qualfier only affects user
536 lookups; both LDAP and sudoers will be queried for Defaults entries.
537 If the /etc/netsvc.conf file is not present or there is no sudoers line,
539 the following default is assumed:
540 sudoers = files
542
544 /etc/sudo-ldap.conf LDAP configuration file
545 /etc/nsswitch.conf determines sudoers source order
547 /etc/netsvc.conf determines sudoers source order on AIX
549
551 Example ldap.conf
552 # Either specify one or more URIs or one or more host:port pairs.
553 # If neither is specified sudo will default to localhost, port 389.
554 #
555 #host ldapserver
556 #host ldapserver1 ldapserver2:390
557 #
558 # Default port if host is specified without one, defaults to 389.
559 #port 389
560 #
561 # URI will override the host and port settings.
562 uri ldap://ldapserver
563 #uri ldaps://secureldapserver
564 #uri ldaps://secureldapserver ldap://ldapserver
565 #
566 # The amount of time, in seconds, to wait while trying to connect to
567 # an LDAP server.
568 bind_timelimit 30
569 #
570 # The amount of time, in seconds, to wait while performing an LDAP query.
571 timelimit 30
572 #
573 # Must be set or sudo will ignore LDAP; may be specified multiple times.
574 sudoers_base ou=SUDOers,dc=example,dc=com
575 #
576 # verbose sudoers matching from ldap
577 #sudoers_debug 2
578 #
579 # Enable support for time-based entries in sudoers.
580 #sudoers_timed yes
581 #
582 # optional proxy credentials
583 #binddn <who to search as>
584 #bindpw <password>
585 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
586 #
587 # LDAP protocol version, defaults to 3
588 #ldap_version 3
589 #
590 # Define if you want to use an encrypted LDAP connection.
591 # Typically, you must also set the port to 636 (ldaps).
592 #ssl on
593 #
594 # Define if you want to use port 389 and switch to
595 # encryption before the bind credentials are sent.
596 # Only supported by LDAP servers that support the start_tls
597 # extension such as OpenLDAP.
598 #ssl start_tls
599 #
600 # Additional TLS options follow that allow tweaking of the
601 # SSL/TLS connection.
602 #
603 #tls_checkpeer yes # verify server SSL certificate
604 #tls_checkpeer no # ignore server SSL certificate
605 #
606 # If you enable tls_checkpeer, specify either tls_cacertfile
607 # or tls_cacertdir. Only supported when using OpenLDAP.
608 #
609 #tls_cacertfile /etc/certs/trusted_signers.pem
610 #tls_cacertdir /etc/certs
611 #
612 # For systems that don't have /dev/random
613 # use this along with PRNGD or EGD.pl to seed the
614 # random number pool to generate cryptographic session keys.
615 # Only supported when using OpenLDAP.
616 #
617 #tls_randfile /etc/egd-pool
618 #
619 # You may restrict which ciphers are used. Consult your SSL
620 # documentation for which options go here.
621 # Only supported when using OpenLDAP.
622 #
623 #tls_ciphers <cipher-list>
624 #
625 # Sudo can provide a client certificate when communicating to
626 # the LDAP server.
627 # Tips:
628 # * Enable both lines at the same time.
629 # * Do not password protect the key file.
630 # * Ensure the keyfile is only readable by root.
631 #
632 # For OpenLDAP:
633 #tls_cert /etc/certs/client_cert.pem
634 #tls_key /etc/certs/client_key.pem
635 #
636 # For SunONE or iPlanet LDAP, tls_cert and tls_key may specify either
637 # a directory, in which case the files in the directory must have the
638 # default names (e.g. cert8.db and key4.db), or the path to the cert
639 # and key files themselves. However, a bug in version 5.0 of the LDAP
640 # SDK will prevent specific file names from working. For this reason
641 # it is suggested that tls_cert and tls_key be set to a directory,
642 # not a file name.
643 #
644 # The certificate database specified by tls_cert may contain CA certs
645 # and/or the client's cert. If the client's cert is included, tls_key
646 # should be specified as well.
647 # For backward compatibility, "sslpath" may be used in place of tls_cert.
648 #tls_cert /var/ldap
649 #tls_key /var/ldap
650 #
651 # If using SASL authentication for LDAP (OpenSSL)
652 # use_sasl yes
653 # sasl_auth_id <SASL user name>
654 # rootuse_sasl yes
655 # rootsasl_auth_id <SASL user name for root access>
656 # sasl_secprops none
657 # krb5_ccname /etc/.ldapcache
658 Sudo schema for OpenLDAP
660 The following schema, in OpenLDAP format, is included with sudo source
661 and binary distributions as schema.OpenLDAP. Simply copy it to the
662 schema directory (e.g. /etc/openldap/schema), add the proper include line
663 in slapd.conf and restart slapd.
664 attributetype ( 1.3.6.1.4.1.15953.9.1.1
666 NAME 'sudoUser'
667 DESC 'User(s) who may run sudo'
668 EQUALITY caseExactIA5Match
669 SUBSTR caseExactIA5SubstringsMatch
670 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
671 attributetype ( 1.3.6.1.4.1.15953.9.1.2
673 NAME 'sudoHost'
674 DESC 'Host(s) who may run sudo'
675 EQUALITY caseExactIA5Match
676 SUBSTR caseExactIA5SubstringsMatch
677 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
678 attributetype ( 1.3.6.1.4.1.15953.9.1.3
680 NAME 'sudoCommand'
681 DESC 'Command(s) to be executed by sudo'
682 EQUALITY caseExactIA5Match
683 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
684 attributetype ( 1.3.6.1.4.1.15953.9.1.4
686 NAME 'sudoRunAs'
687 DESC 'User(s) impersonated by sudo'
688 EQUALITY caseExactIA5Match
689 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
690 attributetype ( 1.3.6.1.4.1.15953.9.1.5
692 NAME 'sudoOption'
693 DESC 'Options(s) followed by sudo'
694 EQUALITY caseExactIA5Match
695 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
696 attributetype ( 1.3.6.1.4.1.15953.9.1.6
698 NAME 'sudoRunAsUser'
699 DESC 'User(s) impersonated by sudo'
700 EQUALITY caseExactIA5Match
701 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
702 attributetype ( 1.3.6.1.4.1.15953.9.1.7
704 NAME 'sudoRunAsGroup'
705 DESC 'Group(s) impersonated by sudo'
706 EQUALITY caseExactIA5Match
707 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
708 attributetype ( 1.3.6.1.4.1.15953.9.1.8
710 NAME 'sudoNotBefore'
711 DESC 'Start of time interval for which the entry is valid'
712 EQUALITY generalizedTimeMatch
713 ORDERING generalizedTimeOrderingMatch
714 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
715 attributetype ( 1.3.6.1.4.1.15953.9.1.9
717 NAME 'sudoNotAfter'
718 DESC 'End of time interval for which the entry is valid'
719 EQUALITY generalizedTimeMatch
720 ORDERING generalizedTimeOrderingMatch
721 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
722 attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
724 NAME 'sudoOrder'
725 DESC 'an integer to order the sudoRole entries'
726 EQUALITY integerMatch
727 ORDERING integerOrderingMatch
728 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
729 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
731 DESC 'Sudoer Entries'
732 MUST ( cn )
733 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
734 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
735 sudoOrder $ description )
736 )
737
739 ldap.conf(8), sudoers(8)
740
742 Note that there are differences in the way that LDAP-based sudoers is
743 parsed compared to file-based sudoers. See the Differences between LDAP
744 and non-LDAP sudoers section for more information.
745
747 If you feel you have found a bug in sudo, please submit a bug report at
748 http://www.sudo.ws/sudo/bugs/
749
751 Limited free support is available via the sudo-users mailing list, see
752 http://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the
753 archives.
754
756 sudo is provided “AS IS” and any express or implied warranties, includ‐
757 ing, but not limited to, the implied warranties of merchantability and
758 fitness for a particular purpose are disclaimed. See the LICENSE file
759 distributed with sudo or http://www.sudo.ws/sudo/license.html for com‐
760 plete details.
761Sudo 1.8.6p3 July 12, 2012 Sudo 1.8.6p3