1SUDOERS.LDAP(5) MAINTENANCE COMMANDS SUDOERS.LDAP(5)
2
6 sudoers.ldap - sudo LDAP configuration
7
9 In addition to the standard sudoers file, sudo may be configured via
10 LDAP. This can be especially useful for synchronizing sudoers in a
11 large, distributed environment.
12 Using LDAP for sudoers has several benefits:
14 · sudo no longer needs to read sudoers in its entirety. When LDAP is
16 used, there are only two or three LDAP queries per invocation.
17 This makes it especially fast and particularly usable in LDAP
18 environments.
19 · sudo no longer exits if there is a typo in sudoers. It is not
21 possible to load LDAP data into the server that does not conform to
22 the sudoers schema, so proper syntax is guaranteed. It is still
23 possible to have typos in a user or host name, but this will not
24 prevent sudo from running.
25 · It is possible to specify per-entry options that override the
27 global default options. /etc/sudoers only supports default options
28 and limited options associated with user/host/commands/aliases.
29 The syntax is complicated and can be difficult for users to
30 understand. Placing the options directly in the entry is more
31 natural.
32 · The visudo program is no longer needed. visudo provides locking
34 and syntax checking of the /etc/sudoers file. Since LDAP updates
35 are atomic, locking is no longer necessary. Because syntax is
36 checked when the data is inserted into LDAP, there is no need for a
37 specialized tool to check syntax.
38 Another major difference between LDAP and file-based sudoers is that in
40 LDAP, sudo-specific Aliases are not supported.
41 For the most part, there is really no need for sudo-specific Aliases.
43 Unix groups or user netgroups can be used in place of User_Aliases and
44 RunasAliases. Host netgroups can be used in place of HostAliases.
45 Since Unix groups and netgroups can also be stored in LDAP there is no
46 real need for sudo-specific aliases.
47 Cmnd_Aliases are not really required either since it is possible to
49 have multiple users listed in a sudoRole. Instead of defining a
50 Cmnd_Alias that is referenced by multiple users, one can create a
51 sudoRole that contains the commands and assign multiple users to it.
52 SUDOers LDAP container
54 The sudoers configuration is contained in the ou=SUDOers LDAP
55 container.
56 Sudo first looks for the cn=default entry in the SUDOers container. If
58 found, the multi-valued sudoOption attribute is parsed in the same
59 manner as a global Defaults line in /etc/sudoers. In the following
60 example, the SSH_AUTH_SOCK variable will be preserved in the
61 environment for all users.
62 dn: cn=defaults,ou=SUDOers,dc=example,dc=com
64 objectClass: top
65 objectClass: sudoRole
66 cn: defaults
67 description: Default sudoOption's go here
68 sudoOption: env_keep+=SSH_AUTH_SOCK
69 The equivalent of a sudoer in LDAP is a sudoRole. It consists of the
71 following components:
72 sudoUser
74 A user name, uid (prefixed with '#'), Unix group (prefixed with a
75 '%') or user netgroup (prefixed with a '+').
76 sudoHost
78 A host name, IP address, IP network, or host netgroup (prefixed
79 with a '+'). The special value ALL will match any host.
80 sudoCommand
82 A Unix command with optional command line arguments, potentially
83 including globbing characters (aka wild cards). The special value
84 ALL will match any command. If a command is prefixed with an
85 exclamation point '!', the user will be prohibited from running
86 that command.
87 sudoOption
89 Identical in function to the global options described above, but
90 specific to the sudoRole in which it resides.
91 sudoRunAsUser
93 A user name or uid (prefixed with '#') that commands may be run as
94 or a Unix group (prefixed with a '%') or user netgroup (prefixed
95 with a '+') that contains a list of users that commands may be run
96 as. The special value ALL will match any user.
97 sudoRunAsGroup
99 A Unix group or gid (prefixed with '#') that commands may be run
100 as. The special value ALL will match any group.
101 Each component listed above should contain a single value, but there
103 may be multiple instances of each component type. A sudoRole must
104 contain at least one sudoUser, sudoHost and sudoCommand.
105 The following example allows users in group wheel to run any command on
107 any host via sudo:
108 dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
110 objectClass: top
111 objectClass: sudoRole
112 cn: %wheel
113 sudoUser: %wheel
114 sudoHost: ALL
115 sudoCommand: ALL
116 Anatomy of LDAP sudoers lookup
118 When looking up a sudoer using LDAP there are only two or three LDAP
119 queries per invocation. The first query is to parse the global
120 options. The second is to match against the user's name and the groups
121 that the user belongs to. (The special ALL tag is matched in this
122 query too.) If no match is returned for the user's name and groups, a
123 third query returns all entries containing user netgroups and checks to
124 see if the user belongs to any of them.
125 Differences between LDAP and non-LDAP sudoers
127 There are some subtle differences in the way sudoers is handled once in
128 LDAP. Probably the biggest is that according to the RFC, LDAP ordering
129 is arbitrary and you cannot expect that Attributes and Entries are
130 returned in any specific order. If there are conflicting command rules
131 on an entry, the negative takes precedence. This is called paranoid
132 behavior (not necessarily the most specific match).
133 Here is an example:
135 # /etc/sudoers:
137 # Allow all commands except shell
138 johnny ALL=(root) ALL,!/bin/sh
139 # Always allows all commands because ALL is matched last
140 puddles ALL=(root) !/bin/sh,ALL
141 # LDAP equivalent of johnny
143 # Allows all commands except shell
144 dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
145 objectClass: sudoRole
146 objectClass: top
147 cn: role1
148 sudoUser: johnny
149 sudoHost: ALL
150 sudoCommand: ALL
151 sudoCommand: !/bin/sh
152 # LDAP equivalent of puddles
154 # Notice that even though ALL comes last, it still behaves like
155 # role1 since the LDAP code assumes the more paranoid configuration
156 dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
157 objectClass: sudoRole
158 objectClass: top
159 cn: role2
160 sudoUser: puddles
161 sudoHost: ALL
162 sudoCommand: !/bin/sh
163 sudoCommand: ALL
164 Another difference is that negations on the Host, User or Runas are
166 currently ignorred. For example, the following attributes do not
167 behave the way one might expect.
168 # does not match all but joe
170 # rather, does not match anyone
171 sudoUser: !joe
172 # does not match all but joe
174 # rather, matches everyone including Joe
175 sudoUser: ALL
176 sudoUser: !joe
177 # does not match all but web01
179 # rather, matches all hosts including web01
180 sudoHost: ALL
181 sudoHost: !web01
182 Sudoers Schema
184 In order to use sudo's LDAP support, the sudo schema must be installed
185 on your LDAP server. In addition, be sure to index the 'sudoUser'
186 attribute.
187 Three versions of the schema: one for OpenLDAP servers
189 (schema.OpenLDAP), one for Netscape-derived servers (schema.iPlanet),
190 and one for Microsoft Active Directory (schema.ActiveDirectory) may be
191 found in the sudo distribution.
192 The schema for sudo in OpenLDAP form is included in the EXAMPLES
194 section.
195 Configuring ldap.conf
197 Sudo reads the /etc/nss_ldap.conf file for LDAP-specific configuration.
198 Typically, this file is shared amongst different LDAP-aware clients.
199 As such, most of the settings are not sudo-specific. Note that sudo
200 parses /etc/nss_ldap.conf itself and may support options that differ
201 from those described in the ldap.conf(5) manual.
202 Also note that on systems using the OpenLDAP libraries, default values
204 specified in /etc/openldap/ldap.conf or the user's .ldaprc files are
205 not used.
206 Only those options explicitly listed in /etc/nss_ldap.conf that are
208 supported by sudo are honored. Configuration options are listed below
209 in upper case but are parsed in a case-independent manner.
210 URI ldap[s]://[hostname[:port]] ...
212 Specifies a whitespace-delimited list of one or more URIs
213 describing the LDAP server(s) to connect to. The protocol may be
214 either ldap or ldaps, the latter being for servers that support TLS
215 (SSL) encryption. If no port is specified, the default is port 389
216 for ldap:// or port 636 for ldaps://. If no hostname is specified,
217 sudo will connect to localhost. Multiple URI lines are treated
218 identically to a URI line containing multiple entries. Only
219 systems using the OpenSSL libraries support the mixing of ldap://
220 and ldaps:// URIs. The Netscape-derived libraries used on most
221 commercial versions of Unix are only capable of supporting one or
222 the other.
223 HOST name[:port] ...
225 If no URI is specified, the HOST parameter specifies a whitespace-
226 delimited list of LDAP servers to connect to. Each host may
227 include an optional port separated by a colon (':'). The HOST
228 parameter is deprecated in favor of the URI specification and is
229 included for backwards compatibility.
230 PORT port_number
232 If no URI is specified, the PORT parameter specifies the default
233 port to connect to on the LDAP server if a HOST parameter does not
234 specify the port itself. If no PORT parameter is used, the default
235 is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The
236 PORT parameter is deprecated in favor of the URI specification and
237 is included for backwards compatibility.
238 BIND_TIMELIMIT seconds
240 The BIND_TIMELIMIT parameter specifies the amount of time, in
241 seconds, to wait while trying to connect to an LDAP server. If
242 multiple URIs or HOSTs are specified, this is the amount of time to
243 wait before trying the next one in the list.
244 TIMELIMIT seconds
246 The TIMELIMIT parameter specifies the amount of time, in seconds,
247 to wait for a response to an LDAP query.
248 SUDOERS_BASE base
250 The base DN to use when performing sudo LDAP queries. Typically
251 this is of the form ou=SUDOers,dc=example,dc=com for the domain
252 example.com. Multiple SUDOERS_BASE lines may be specified, in
253 which case they are queried in the order specified.
254 SUDOERS_DEBUG debug_level
256 This sets the debug level for sudo LDAP queries. Debugging
257 information is printed to the standard error. A value of 1 results
258 in a moderate amount of debugging information. A value of 2 shows
259 the results of the matches themselves. This parameter should not
260 be set in a production environment as the extra information is
261 likely to confuse users.
262 BINDDN DN
264 The BINDDN parameter specifies the identity, in the form of a
265 Distinguished Name (DN), to use when performing LDAP operations.
266 If not specified, LDAP operations are performed with an anonymous
267 identity. By default, most LDAP servers will allow anonymous
268 access.
269 BINDPW secret
271 The BINDPW parameter specifies the password to use when performing
272 LDAP operations. This is typically used in conjunction with the
273 BINDDN parameter.
274 ROOTBINDDN DN
276 The ROOTBINDDN parameter specifies the identity, in the form of a
277 Distinguished Name (DN), to use when performing privileged LDAP
278 operations, such as sudoers queries. The password corresponding to
279 the identity should be stored in /etc/nss_ldap.secret. If not
280 specified, the BINDDN identity is used (if any).
281 LDAP_VERSION number
283 The version of the LDAP protocol to use when connecting to the
284 server. The default value is protocol version 3.
285 SSL on/true/yes/off/false/no
287 If the SSL parameter is set to on, true or yes, TLS (SSL)
288 encryption is always used when communicating with the LDAP server.
289 Typically, this involves connecting to the server on port 636
290 (ldaps).
291 SSL start_tls
293 If the SSL parameter is set to start_tls, the LDAP server
294 connection is initiated normally and TLS encryption is begun before
295 the bind credentials are sent. This has the advantage of not
296 requiring a dedicated port for encrypted communications. This
297 parameter is only supported by LDAP servers that honor the
298 start_tls extension, such as the OpenLDAP server.
299 TLS_CHECKPEER on/true/yes/off/false/no
301 If enabled, TLS_CHECKPEER will cause the LDAP server's TLS
302 certificated to be verified. If the server's TLS certificate
303 cannot be verified (usually because it is signed by an unknown
304 certificate authority), sudo will be unable to connect to it. If
305 TLS_CHECKPEER is disabled, no check is made. Note that disabling
306 the check creates an opportunity for man-in-the-middle attacks
307 since the server's identity will not be authenticated. If
308 possible, the CA's certificate should be installed locally so it
309 can be verified.
310 TLS_CACERT file name
312 An alias for TLS_CACERTFILE.
313 TLS_CACERTFILE file name
315 The path to a certificate authority bundle which contains the
316 certificates for all the Certificate Authorities the client knows
317 to be valid, e.g. /etc/ssl/ca-bundle.pem. This option is only
318 supported by the OpenLDAP libraries. Netscape-derived LDAP
319 libraries use the same certificate database for CA and client
320 certificates (see TLS_CERT).
321 TLS_CACERTDIR directory
323 Similar to TLS_CACERTFILE but instead of a file, it is a directory
324 containing individual Certificate Authority certificates, e.g.
325 /etc/ssl/certs. The directory specified by TLS_CACERTDIR is
326 checked after TLS_CACERTFILE. This option is only supported by the
327 OpenLDAP libraries.
328 TLS_CERT file name
330 The path to a file containing the client certificate which can be
331 used to authenticate the client to the LDAP server. The
332 certificate type depends on the LDAP libraries used.
333 OpenLDAP:
335 tls_cert /etc/ssl/client_cert.pem
336 Netscape-derived:
338 tls_cert /var/ldap/cert7.db
339 When using Netscape-derived libraries, this file may also contain
341 Certificate Authority certificates.
342 TLS_KEY file name
344 The path to a file containing the private key which matches the
345 certificate specified by TLS_CERT. The private key must not be
346 password-protected. The key type depends on the LDAP libraries
347 used.
348 OpenLDAP:
350 tls_key /etc/ssl/client_key.pem
351 Netscape-derived:
353 tls_key /var/ldap/key3.db
354 TLS_RANDFILE file name
356 The TLS_RANDFILE parameter specifies the path to an entropy source
357 for systems that lack a random device. It is generally used in
358 conjunction with prngd or egd. This option is only supported by
359 the OpenLDAP libraries.
360 TLS_CIPHERS cipher list
362 The TLS_CIPHERS parameter allows the administer to restrict which
363 encryption algorithms may be used for TLS (SSL) connections. See
364 the OpenSSL manual for a list of valid ciphers. This option is
365 only supported by the OpenLDAP libraries.
366 USE_SASL on/true/yes/off/false/no
368 Enable USE_SASL for LDAP servers that support SASL authentication.
369 SASL_AUTH_ID identity
371 The SASL user name to use when connecting to the LDAP server. By
372 default, sudo will use an anonymous connection.
373 ROOTUSE_SASL on/true/yes/off/false/no
375 Enable ROOTUSE_SASL to enable SASL authentication when connecting
376 to an LDAP server from a privileged process, such as sudo.
377 ROOTSASL_AUTH_ID identity
379 The SASL user name to use when ROOTUSE_SASL is enabled.
380 SASL_SECPROPS none/properties
382 SASL security properties or none for no properties. See the SASL
383 programmer's manual for details.
384 KRB5_CCNAME file name
386 The path to the Kerberos 5 credential cache to use when
387 authenticating with the remote server.
388 See the ldap.conf entry in the EXAMPLES section.
390 Configuring nsswitch.conf
392 Unless it is disabled at build time, sudo consults the Name Service
393 Switch file, /etc/nsswitch.conf, to specify the sudoers search order.
394 Sudo looks for a line beginning with sudoers: and uses this to
395 determine the search order. Note that sudo does not stop searching
396 after the first match and later matches take precedence over earlier
397 ones.
398 The following sources are recognized:
400 files read sudoers from F</etc/sudoers>
402 ldap read sudoers from LDAP
403 In addition, the entry [NOTFOUND=return] will short-circuit the search
405 if the user was not found in the preceding source.
406 To consult LDAP first followed by the local sudoers file (if it
408 exists), use:
409 sudoers: ldap files
411 The local sudoers file can be ignored completely by using:
413 sudoers: ldap
415 If the /etc/nsswitch.conf file is not present or there is no sudoers
417 line, the following default is assumed:
418 sudoers: files
420 Note that /etc/nsswitch.conf is supported even when the underlying
422 operating system does not use an nsswitch.conf file.
423 Configuring netsvc.conf
425 On AIX systems, the /etc/netsvc.conf file is consulted instead of
426 /etc/nsswitch.conf. sudo simply treats netsvc.conf as a variant of
427 nsswitch.conf; information in the previous section unrelated to the
428 file format itself still applies.
429 To consult LDAP first followed by the local sudoers file (if it
431 exists), use:
432 sudoers = ldap, files
434 The local sudoers file can be ignored completely by using:
436 sudoers = ldap
438 To treat LDAP as authoratative and only use the local sudoers file if
440 the user is not present in LDAP, use:
441 sudoers = ldap = auth, files
443 Note that in the above example, the auth qualfier only affects user
445 lookups; both LDAP and sudoers will be queried for Defaults entries.
446 If the /etc/netsvc.conf file is not present or there is no sudoers
448 line, the following default is assumed:
449 sudoers = files
451
453 /etc/nss_ldap.conf LDAP configuration file
454 /etc/nsswitch.conf determines sudoers source order
456 /etc/netsvc.conf determines sudoers source order on AIX
458
460 Example ldap.conf
461 # Either specify one or more URIs or one or more host:port pairs.
462 # If neither is specified sudo will default to localhost, port 389.
463 #
464 #host ldapserver
465 #host ldapserver1 ldapserver2:390
466 #
467 # Default port if host is specified without one, defaults to 389.
468 #port 389
469 #
470 # URI will override the host and port settings.
471 uri ldap://ldapserver
472 #uri ldaps://secureldapserver
473 #uri ldaps://secureldapserver ldap://ldapserver
474 #
475 # The amount of time, in seconds, to wait while trying to connect to
476 # an LDAP server.
477 bind_timelimit 30
478 #
479 # The amount of time, in seconds, to wait while performing an LDAP query.
480 timelimit 30
481 #
482 # Must be set or sudo will ignore LDAP; may be specified multiple times.
483 sudoers_base ou=SUDOers,dc=example,dc=com
484 #
485 # verbose sudoers matching from ldap
486 #sudoers_debug 2
487 #
488 # optional proxy credentials
489 #binddn <who to search as>
490 #bindpw <password>
491 #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
492 #
493 # LDAP protocol version, defaults to 3
494 #ldap_version 3
495 #
496 # Define if you want to use an encrypted LDAP connection.
497 # Typically, you must also set the port to 636 (ldaps).
498 #ssl on
499 #
500 # Define if you want to use port 389 and switch to
501 # encryption before the bind credentials are sent.
502 # Only supported by LDAP servers that support the start_tls
503 # extension such as OpenLDAP.
504 #ssl start_tls
505 #
506 # Additional TLS options follow that allow tweaking of the
507 # SSL/TLS connection.
508 #
509 #tls_checkpeer yes # verify server SSL certificate
510 #tls_checkpeer no # ignore server SSL certificate
511 #
512 # If you enable tls_checkpeer, specify either tls_cacertfile
513 # or tls_cacertdir. Only supported when using OpenLDAP.
514 #
515 #tls_cacertfile /etc/certs/trusted_signers.pem
516 #tls_cacertdir /etc/certs
517 #
518 # For systems that don't have /dev/random
519 # use this along with PRNGD or EGD.pl to seed the
520 # random number pool to generate cryptographic session keys.
521 # Only supported when using OpenLDAP.
522 #
523 #tls_randfile /etc/egd-pool
524 #
525 # You may restrict which ciphers are used. Consult your SSL
526 # documentation for which options go here.
527 # Only supported when using OpenLDAP.
528 #
529 #tls_ciphers <cipher-list>
530 #
531 # Sudo can provide a client certificate when communicating to
532 # the LDAP server.
533 # Tips:
534 # * Enable both lines at the same time.
535 # * Do not password protect the key file.
536 # * Ensure the keyfile is only readable by root.
537 #
538 # For OpenLDAP:
539 #tls_cert /etc/certs/client_cert.pem
540 #tls_key /etc/certs/client_key.pem
541 #
542 # For SunONE or iPlanet LDAP, tls_cert and tls_key may specify either
543 # a directory, in which case the files in the directory must have the
544 # default names (e.g. cert8.db and key4.db), or the path to the cert
545 # and key files themselves. However, a bug in version 5.0 of the LDAP
546 # SDK will prevent specific file names from working. For this reason
547 # it is suggested that tls_cert and tls_key be set to a directory,
548 # not a file name.
549 #
550 # The certificate database specified by tls_cert may contain CA certs
551 # and/or the client's cert. If the client's cert is included, tls_key
552 # should be specified as well.
553 # For backward compatibility, "sslpath" may be used in place of tls_cert.
554 #tls_cert /var/ldap
555 #tls_key /var/ldap
556 #
557 # If using SASL authentication for LDAP (OpenSSL)
558 # use_sasl yes
559 # sasl_auth_id <SASL user name>
560 # rootuse_sasl yes
561 # rootsasl_auth_id <SASL user name for root access>
562 # sasl_secprops none
563 # krb5_ccname /etc/.ldapcache
564 Sudo schema for OpenLDAP
566 The following schema is in OpenLDAP format. Simply copy it to the
567 schema directory (e.g. /etc/openldap/schema), add the proper include
568 line in slapd.conf and restart slapd.
569 attributetype ( 1.3.6.1.4.1.15953.9.1.1
571 NAME 'sudoUser'
572 DESC 'User(s) who may run sudo'
573 EQUALITY caseExactIA5Match
574 SUBSTR caseExactIA5SubstringsMatch
575 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
576 attributetype ( 1.3.6.1.4.1.15953.9.1.2
578 NAME 'sudoHost'
579 DESC 'Host(s) who may run sudo'
580 EQUALITY caseExactIA5Match
581 SUBSTR caseExactIA5SubstringsMatch
582 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
583 attributetype ( 1.3.6.1.4.1.15953.9.1.3
585 NAME 'sudoCommand'
586 DESC 'Command(s) to be executed by sudo'
587 EQUALITY caseExactIA5Match
588 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
589 attributetype ( 1.3.6.1.4.1.15953.9.1.4
591 NAME 'sudoRunAs'
592 DESC 'User(s) impersonated by sudo'
593 EQUALITY caseExactIA5Match
594 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
595 attributetype ( 1.3.6.1.4.1.15953.9.1.5
597 NAME 'sudoOption'
598 DESC 'Options(s) followed by sudo'
599 EQUALITY caseExactIA5Match
600 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
601 attributetype ( 1.3.6.1.4.1.15953.9.1.6
603 NAME 'sudoRunAsUser'
604 DESC 'User(s) impersonated by sudo'
605 EQUALITY caseExactIA5Match
606 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
607 attributetype ( 1.3.6.1.4.1.15953.9.1.7
609 NAME 'sudoRunAsGroup'
610 DESC 'Group(s) impersonated by sudo'
611 EQUALITY caseExactIA5Match
612 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
613 objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
615 DESC 'Sudoer Entries'
616 MUST ( cn )
617 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
618 sudoRunAsGroup $ sudoOption $ description )
619 )
620
622 ldap.conf(5), sudoers(5)
623
625 The way that sudoers is parsed differs between Note that there are
626 differences in the way that LDAP-based sudoers is parsed compared to
627 file-based sudoers. See the "Differences between LDAP and non-LDAP
628 sudoers" section for more information.
629
631 If you feel you have found a bug in sudo, please submit a bug report at
632 http://www.sudo.ws/sudo/bugs/
633
635 Limited free support is available via the sudo-users mailing list, see
636 http://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
637 the archives.
638
640 sudo is provided ``AS IS'' and any express or implied warranties,
641 including, but not limited to, the implied warranties of
642 merchantability and fitness for a particular purpose are disclaimed.
643 See the LICENSE file distributed with sudo or
644 http://www.sudo.ws/sudo/license.html for complete details.
6451.7.4 July 12, 2010 SUDOERS.LDAP(5)