Merge tag 'debian/1.8.5p2-1' into squeeze
[debian/sudo] / doc / sudoers.ldap.pod
diff --git a/doc/sudoers.ldap.pod b/doc/sudoers.ldap.pod
new file mode 100644 (file)
index 0000000..f6a2bee
--- /dev/null
@@ -0,0 +1,849 @@
+Copyright (c) 2003-2011
+       Todd C. Miller <Todd.Miller@courtesan.com>
+
+Permission to use, copy, modify, and distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+=pod
+
+=head1 NAME
+
+sudoers.ldap - sudo LDAP configuration
+
+=head1 DESCRIPTION
+
+In addition to the standard I<sudoers> file, B<sudo> may be configured
+via LDAP.  This can be especially useful for synchronizing I<sudoers>
+in a large, distributed environment.
+
+Using LDAP for I<sudoers> has several benefits:
+
+=over 4
+
+=item *
+
+B<sudo> no longer needs to read I<sudoers> in its entirety.  When
+LDAP is used, there are only two or three LDAP queries per invocation.
+This makes it especially fast and particularly usable in LDAP
+environments.
+
+=item *
+
+B<sudo> no longer exits if there is a typo in I<sudoers>.
+It is not possible to load LDAP data into the server that does
+not conform to the sudoers schema, so proper syntax is guaranteed.
+It is still possible to have typos in a user or host name, but
+this will not prevent B<sudo> from running.
+
+=item *
+
+It is possible to specify per-entry options that override the global
+default options.  F<@sysconfdir@/sudoers> only supports default options and
+limited options associated with user/host/commands/aliases.  The
+syntax is complicated and can be difficult for users to understand.
+Placing the options directly in the entry is more natural.
+
+=item *
+
+The B<visudo> program is no longer needed.  B<visudo> provides
+locking and syntax checking of the F<@sysconfdir@/sudoers> file.
+Since LDAP updates are atomic, locking is no longer necessary.
+Because syntax is checked when the data is inserted into LDAP, there
+is no need for a specialized tool to check syntax.
+
+=back
+
+Another major difference between LDAP and file-based I<sudoers>
+is that in LDAP, B<sudo>-specific Aliases are not supported.
+
+For the most part, there is really no need for B<sudo>-specific
+Aliases.  Unix groups or user netgroups can be used in place of
+User_Aliases and Runas_Aliases.  Host netgroups can be used in place
+of Host_Aliases.  Since Unix groups and netgroups can also be stored
+in LDAP there is no real need for B<sudo>-specific aliases.
+
+Cmnd_Aliases are not really required either since it is possible
+to have multiple users listed in a C<sudoRole>.  Instead of defining
+a Cmnd_Alias that is referenced by multiple users, one can create
+a C<sudoRole> that contains the commands and assign multiple users
+to it.
+
+=head2 SUDOers LDAP container
+
+The I<sudoers> configuration is contained in the C<ou=SUDOers> LDAP
+container.
+
+Sudo first looks for the C<cn=default> entry in the SUDOers container.
+If found, the multi-valued C<sudoOption> attribute is parsed in the
+same manner as a global C<Defaults> line in F<@sysconfdir@/sudoers>.  In
+the following example, the C<SSH_AUTH_SOCK> variable will be preserved
+in the environment for all users.
+
+    dn: cn=defaults,ou=SUDOers,dc=example,dc=com
+    objectClass: top
+    objectClass: sudoRole
+    cn: defaults
+    description: Default sudoOption's go here
+    sudoOption: env_keep+=SSH_AUTH_SOCK
+The equivalent of a sudoer in LDAP is a C<sudoRole>.  It consists of
+the following attributes:
+
+=over 4
+
+=item B<sudoUser>
+
+A user name, user ID (prefixed with C<'#'>), Unix group (prefixed with
+C<'%'>), Unix group ID (prefixed with C<'%#'>), or user netgroup
+(prefixed with C<'+'>).
+
+=item B<sudoHost>
+
+A host name, IP address, IP network, or host netgroup (prefixed
+with a C<'+'>).
+The special value C<ALL> will match any host.
+
+=item B<sudoCommand>
+
+A Unix command with optional command line arguments, potentially
+including globbing characters (aka wild cards).
+The special value C<ALL> will match any command.
+If a command is prefixed with an exclamation point C<'!'>, the
+user will be prohibited from running that command.
+
+=item B<sudoOption>
+
+Identical in function to the global options described above, but
+specific to the C<sudoRole> in which it resides.
+
+=item B<sudoRunAsUser>
+
+A user name or uid (prefixed with C<'#'>) that commands may be run
+as or a Unix group (prefixed with a C<'%'>) or user netgroup (prefixed
+with a C<'+'>) that contains a list of users that commands may be
+run as.
+The special value C<ALL> will match any user.
+
+The C<sudoRunAsUser> attribute is only available in B<sudo> versions
+1.7.0 and higher.  Older versions of B<sudo> use the C<sudoRunAs>
+attribute instead.
+
+=item B<sudoRunAsGroup>
+
+A Unix group or gid (prefixed with C<'#'>) that commands may be run as.
+The special value C<ALL> will match any group.
+
+The C<sudoRunAsGroup> attribute is only available in B<sudo> versions
+1.7.0 and higher.
+
+=item B<sudoNotBefore>
+
+A timestamp in the form C<yyyymmddHHMMSSZ> that can be used to provide
+a start date/time for when the C<sudoRole> will be valid.  If
+multiple C<sudoNotBefore> entries are present, the earliest is used.
+Note that timestamps must be in Coordinated Universal Time (UTC),
+not the local timezone.  The minute and seconds portions are optional,
+but some LDAP servers require that they be present (contrary to the RFC).
+
+The C<sudoNotBefore> attribute is only available in B<sudo> versions
+1.7.5 and higher and must be explicitly enabled via the B<SUDOERS_TIMED>
+option in F<@ldap_conf@>.
+
+=item B<sudoNotAfter>
+
+A timestamp in the form C<yyyymmddHHMMSSZ> that indicates an expiration
+date/time, after which the C<sudoRole> will no longer be valid.  If
+multiple C<sudoNotBefore> entries are present, the last one is used.
+Note that timestamps must be in Coordinated Universal Time (UTC),
+not the local timezone.  The minute and seconds portions are optional,
+but some LDAP servers require that they be present (contrary to the RFC).
+
+The C<sudoNotAfter> attribute is only available in B<sudo> versions
+1.7.5 and higher and must be explicitly enabled via the B<SUDOERS_TIMED>
+option in F<@ldap_conf@>.
+
+=item B<sudoOrder>
+
+The C<sudoRole> entries retrieved from the LDAP directory have no
+inherent order.  The C<sudoOrder> attribute is an integer (or
+floating point value for LDAP servers that support it) that is used
+to sort the matching entries.  This allows LDAP-based sudoers entries
+to more closely mimic the behaviour of the sudoers file, where the
+of the entries influences the result.  If multiple entries match,
+the entry with the highest C<sudoOrder> attribute is chosen.  This
+corresponds to the "last match" behavior of the sudoers file.  If
+the C<sudoOrder> attribute is not present, a value of 0 is assumed.
+
+The C<sudoOrder> attribute is only available in B<sudo> versions
+1.7.5 and higher.
+
+=back
+
+Each attribute listed above should contain a single value, but there
+may be multiple instances of each attribute type.  A C<sudoRole> must
+contain at least one C<sudoUser>, C<sudoHost> and C<sudoCommand>.
+
+The following example allows users in group wheel to run any command
+on any host via B<sudo>:
+
+    dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
+    objectClass: top
+    objectClass: sudoRole
+    cn: %wheel
+    sudoUser: %wheel
+    sudoHost: ALL
+    sudoCommand: ALL
+
+=head2 Anatomy of LDAP sudoers lookup
+
+When looking up a sudoer using LDAP there are only two or three
+LDAP queries per invocation.  The first query is to parse the global
+options.  The second is to match against the user's name and the
+groups that the user belongs to.  (The special ALL tag is matched
+in this query too.)  If no match is returned for the user's name
+and groups, a third query returns all entries containing user
+netgroups and checks to see if the user belongs to any of them.
+
+If timed entries are enabled with the B<SUDOERS_TIMED> configuration
+directive, the LDAP queries include a subfilter that limits retrieval
+to entries that satisfy the time constraints, if any.
+
+=head2 Differences between LDAP and non-LDAP sudoers
+
+There are some subtle differences in the way sudoers is handled
+once in LDAP.  Probably the biggest is that according to the RFC,
+LDAP ordering is arbitrary and you cannot expect that Attributes
+and Entries are returned in any specific order.
+
+The order in which different entries are applied can be controlled
+using the C<sudoOrder> attribute, but there is no way to guarantee
+the order of attributes within a specific entry.  If there are
+conflicting command rules in an entry, the negative takes precedence.
+This is called paranoid behavior (not necessarily the most specific
+match).
+
+Here is an example:
+
+    # /etc/sudoers:
+    # Allow all commands except shell
+    johnny  ALL=(root) ALL,!/bin/sh
+    # Always allows all commands because ALL is matched last
+    puddles ALL=(root) !/bin/sh,ALL
+
+    # LDAP equivalent of johnny
+    # Allows all commands except shell
+    dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
+    objectClass: sudoRole
+    objectClass: top
+    cn: role1
+    sudoUser: johnny
+    sudoHost: ALL
+    sudoCommand: ALL
+    sudoCommand: !/bin/sh
+
+    # LDAP equivalent of puddles
+    # Notice that even though ALL comes last, it still behaves like
+    # role1 since the LDAP code assumes the more paranoid configuration
+    dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
+    objectClass: sudoRole
+    objectClass: top
+    cn: role2
+    sudoUser: puddles
+    sudoHost: ALL
+    sudoCommand: !/bin/sh
+    sudoCommand: ALL
+
+Another difference is that negations on the Host, User or Runas are
+currently ignored.  For example, the following attributes do not
+behave the way one might expect.
+
+    # does not match all but joe
+    # rather, does not match anyone
+    sudoUser: !joe
+
+    # does not match all but joe
+    # rather, matches everyone including Joe
+    sudoUser: ALL
+    sudoUser: !joe
+
+    # does not match all but web01
+    # rather, matches all hosts including web01
+    sudoHost: ALL
+    sudoHost: !web01
+
+=head2 Sudoers Schema
+
+In order to use B<sudo>'s LDAP support, the B<sudo> schema must be
+installed on your LDAP server.  In addition, be sure to index the
+'sudoUser' attribute.
+
+Three versions of the schema: one for OpenLDAP servers (F<schema.OpenLDAP>),
+one for Netscape-derived servers (F<schema.iPlanet>), and one for
+Microsoft Active Directory (F<schema.ActiveDirectory>) may
+be found in the B<sudo> distribution.
+
+The schema for B<sudo> in OpenLDAP form is included in the L<EXAMPLES>
+section.
+
+=head2 Configuring ldap.conf
+
+Sudo reads the F<@ldap_conf@> file for LDAP-specific configuration.
+Typically, this file is shared amongst different LDAP-aware clients.
+As such, most of the settings are not B<sudo>-specific.  Note that
+B<sudo> parses F<@ldap_conf@> itself and may support options
+that differ from those described in the L<ldap.conf(5)> manual.
+
+Also note that on systems using the OpenLDAP libraries, default
+values specified in F</etc/openldap/ldap.conf> or the user's
+F<.ldaprc> files are not used.
+
+Only those options explicitly listed in F<@ldap_conf@> as being
+supported by B<sudo> are honored.  Configuration options are listed
+below in upper case but are parsed in a case-independent manner.
+
+=over 4
+
+=item B<URI> ldap[s]://[hostname[:port]] ...
+
+Specifies a whitespace-delimited list of one or more URIs describing
+the LDAP server(s) to connect to.  The I<protocol> may be either
+B<ldap> or B<ldaps>, the latter being for servers that support TLS
+(SSL) encryption.  If no I<port> is specified, the default is port
+389 for C<ldap://> or port 636 for C<ldaps://>.  If no I<hostname>
+is specified, B<sudo> will connect to B<localhost>.  Multiple B<URI>
+lines are treated identically to a B<URI> line containing multiple
+entries.  Only systems using the OpenSSL libraries support the
+mixing of C<ldap://> and C<ldaps://> URIs.  The Netscape-derived
+libraries used on most commercial versions of Unix are only capable
+of supporting one or the other.
+
+=item B<HOST> name[:port] ...
+
+If no B<URI> is specified, the B<HOST> parameter specifies a
+whitespace-delimited list of LDAP servers to connect to.  Each host
+may include an optional I<port> separated by a colon (':').  The
+B<HOST> parameter is deprecated in favor of the B<URI> specification
+and is included for backwards compatibility.
+
+=item B<PORT> port_number
+
+If no B<URI> is specified, the B<PORT> parameter specifies the
+default port to connect to on the LDAP server if a B<HOST> parameter
+does not specify the port itself.  If no B<PORT> parameter is used,
+the default is port 389 for LDAP and port 636 for LDAP over TLS
+(SSL).  The B<PORT> parameter is deprecated in favor of the B<URI>
+specification and is included for backwards compatibility.
+
+=item B<BIND_TIMELIMIT> seconds
+
+The B<BIND_TIMELIMIT> parameter specifies the amount of time, in seconds,
+to wait while trying to connect to an LDAP server.  If multiple B<URI>s or
+B<HOST>s are specified, this is the amount of time to wait before trying
+the next one in the list.
+
+=item B<NETWORK_TIMEOUT> seconds
+
+An alias for B<BIND_TIMELIMIT> for OpenLDAP compatibility.
+
+=item B<TIMELIMIT> seconds
+
+The B<TIMELIMIT> parameter specifies the amount of time, in seconds,
+to wait for a response to an LDAP query.
+
+=item B<TIMEOUT> seconds
+
+The B<TIMEOUT> parameter specifies the amount of time, in seconds,
+to wait for a response from the various LDAP APIs.
+
+=item B<SUDOERS_BASE> base
+
+The base DN to use when performing B<sudo> LDAP queries.  Typically
+this is of the form C<ou=SUDOers,dc=example,dc=com> for the domain
+C<example.com>.  Multiple B<SUDOERS_BASE> lines may be specified,
+in which case they are queried in the order specified.
+
+=item B<SUDOERS_SEARCH_FILTER> ldap_filter
+
+An LDAP filter which is used to restrict the set of records returned
+when performing a B<sudo> LDAP query.  Typically, this is of the
+form C<attribute=value> or C<(&(attribute=value)(attribute2=value2))>.
+
+=item B<SUDOERS_TIMED> on/true/yes/off/false/no
+
+Whether or not to evaluate the C<sudoNotBefore> and C<sudoNotAfter>
+attributes that implement time-dependent sudoers entries.
+
+=item B<SUDOERS_DEBUG> debug_level
+
+This sets the debug level for B<sudo> LDAP queries.  Debugging
+information is printed to the standard error.  A value of 1 results
+in a moderate amount of debugging information.  A value of 2 shows
+the results of the matches themselves.  This parameter should not
+be set in a production environment as the extra information is
+likely to confuse users.
+
+=item B<BINDDN> DN
+
+The B<BINDDN> parameter specifies the identity, in the form of a
+Distinguished Name (DN), to use when performing LDAP operations.
+If not specified, LDAP operations are performed with an anonymous
+identity.  By default, most LDAP servers will allow anonymous access.
+
+=item B<BINDPW> secret
+
+The B<BINDPW> parameter specifies the password to use when performing
+LDAP operations.  This is typically used in conjunction with the
+B<BINDDN> parameter.
+
+=item B<ROOTBINDDN> DN
+
+The B<ROOTBINDDN> parameter specifies the identity, in the form of
+a Distinguished Name (DN), to use when performing privileged LDAP
+operations, such as I<sudoers> queries.  The password corresponding
+to the identity should be stored in F<@ldap_secret@>.
+If not specified, the B<BINDDN> identity is used (if any).
+
+=item B<LDAP_VERSION> number
+
+The version of the LDAP protocol to use when connecting to the server.
+The default value is protocol version 3.
+
+=item B<SSL> on/true/yes/off/false/no
+
+If the B<SSL> parameter is set to C<on>, C<true> or C<yes>, TLS
+(SSL) encryption is always used when communicating with the LDAP
+server.  Typically, this involves connecting to the server on port
+636 (ldaps).
+
+=item B<SSL> start_tls
+
+If the B<SSL> parameter is set to C<start_tls>, the LDAP server
+connection is initiated normally and TLS encryption is begun before
+the bind credentials are sent.  This has the advantage of not
+requiring a dedicated port for encrypted communications.  This
+parameter is only supported by LDAP servers that honor the C<start_tls>
+extension, such as the OpenLDAP server.
+
+=item B<TLS_CHECKPEER> on/true/yes/off/false/no
+
+If enabled, B<TLS_CHECKPEER> will cause the LDAP server's TLS
+certificated to be verified.  If the server's TLS certificate cannot
+be verified (usually because it is signed by an unknown certificate
+authority), B<sudo> will be unable to connect to it.  If B<TLS_CHECKPEER>
+is disabled, no check is made.  Note that disabling the check creates
+an opportunity for man-in-the-middle attacks since the server's
+identity will not be authenticated.  If possible, the CA's certificate
+should be installed locally so it can be verified.
+
+=item B<TLS_CACERT> file name
+
+An alias for B<TLS_CACERTFILE> for OpenLDAP compatibility.
+
+=item B<TLS_CACERTFILE> file name
+
+The path to a certificate authority bundle which contains the certificates
+for all the Certificate Authorities the client knows to be valid,
+e.g. F</etc/ssl/ca-bundle.pem>.
+This option is only supported by the OpenLDAP libraries.
+Netscape-derived LDAP libraries use the same certificate
+database for CA and client certificates (see B<TLS_CERT>).
+
+=item B<TLS_CACERTDIR> directory
+
+Similar to B<TLS_CACERTFILE> but instead of a file, it is a
+directory containing individual Certificate Authority certificates,
+e.g. F</etc/ssl/certs>.
+The directory specified by B<TLS_CACERTDIR> is checked after
+B<TLS_CACERTFILE>.
+This option is only supported by the OpenLDAP libraries.
+
+=item B<TLS_CERT> file name
+
+The path to a file containing the client certificate which can
+be used to authenticate the client to the LDAP server.
+The certificate type depends on the LDAP libraries used.
+
+OpenLDAP:
+    C<tls_cert /etc/ssl/client_cert.pem>
+
+Netscape-derived:
+    C<tls_cert /var/ldap/cert7.db>
+
+When using Netscape-derived libraries, this file may also contain
+Certificate Authority certificates.
+
+=item B<TLS_KEY> file name
+
+The path to a file containing the private key which matches the
+certificate specified by B<TLS_CERT>.  The private key must not be
+password-protected.  The key type depends on the LDAP libraries
+used.
+
+OpenLDAP:
+    C<tls_key /etc/ssl/client_key.pem>
+
+Netscape-derived:
+    C<tls_key /var/ldap/key3.db>
+
+=item B<TLS_RANDFILE> file name
+
+The B<TLS_RANDFILE> parameter specifies the path to an entropy
+source for systems that lack a random device.  It is generally used
+in conjunction with I<prngd> or I<egd>.
+This option is only supported by the OpenLDAP libraries.
+
+=item B<TLS_CIPHERS> cipher list
+
+The B<TLS_CIPHERS> parameter allows the administer to restrict
+which encryption algorithms may be used for TLS (SSL) connections.
+See the OpenSSL manual for a list of valid ciphers.
+This option is only supported by the OpenLDAP libraries.
+
+=item B<USE_SASL> on/true/yes/off/false/no
+
+Enable B<USE_SASL> for LDAP servers that support SASL authentication.
+
+=item B<SASL_AUTH_ID> identity
+
+The SASL user name to use when connecting to the LDAP server.
+By default, B<sudo> will use an anonymous connection.
+
+=item B<ROOTUSE_SASL> on/true/yes/off/false/no
+
+Enable B<ROOTUSE_SASL> to enable SASL authentication when connecting
+to an LDAP server from a privileged process, such as B<sudo>.
+
+=item B<ROOTSASL_AUTH_ID> identity
+
+The SASL user name to use when B<ROOTUSE_SASL> is enabled.
+
+=item B<SASL_SECPROPS> none/properties
+
+SASL security properties or I<none> for no properties.  See the
+SASL programmer's manual for details.
+
+=item B<KRB5_CCNAME> file name
+
+The path to the Kerberos 5 credential cache to use when authenticating
+with the remote server.
+
+=item B<DEREF> never/searching/finding/always
+
+How alias dereferencing is to be performed when searching.  See the
+L<ldap.conf(5)> manual for a full description of this option.
+
+=back
+
+See the C<ldap.conf> entry in the L<EXAMPLES> section.
+
+=head2 Configuring nsswitch.conf
+
+Unless it is disabled at build time, B<sudo> consults the Name
+Service Switch file, F<@nsswitch_conf@>, to specify the I<sudoers>
+search order.  Sudo looks for a line beginning with C<sudoers>: and
+uses this to determine the search order.  Note that B<sudo> does
+not stop searching after the first match and later matches take
+precedence over earlier ones.
+
+The following sources are recognized:
+
+    files      read sudoers from F<@sysconfdir@/sudoers>
+    ldap       read sudoers from LDAP
+
+In addition, the entry C<[NOTFOUND=return]> will short-circuit the
+search if the user was not found in the preceding source.
+
+To consult LDAP first followed by the local sudoers file (if it
+exists), use:
+
+    sudoers: ldap files
+
+The local I<sudoers> file can be ignored completely by using:
+
+    sudoers: ldap
+
+If the F<@nsswitch_conf@> file is not present or there is no
+sudoers line, the following default is assumed:
+
+    sudoers: files
+
+Note that F<@nsswitch_conf@> is supported even when the underlying
+operating system does not use an nsswitch.conf file.
+
+=head2 Configuring netsvc.conf
+
+On AIX systems, the F<@netsvc_conf@> file is consulted instead of
+F<@nsswitch_conf@>.  B<sudo> simply treats I<netsvc.conf> as a
+variant of I<nsswitch.conf>; information in the previous section
+unrelated to the file format itself still applies.
+
+To consult LDAP first followed by the local sudoers file (if it
+exists), use:
+
+    sudoers = ldap, files
+
+The local I<sudoers> file can be ignored completely by using:
+
+    sudoers = ldap
+
+To treat LDAP as authoratative and only use the local sudoers file
+if the user is not present in LDAP, use:
+
+    sudoers = ldap = auth, files
+
+Note that in the above example, the C<auth> qualfier only affects
+user lookups; both LDAP and I<sudoers> will be queried for C<Defaults>
+entries.
+
+If the F<@netsvc_conf@> file is not present or there is no
+sudoers line, the following default is assumed:
+
+    sudoers = files
+
+=head1 FILES
+
+=over 24
+
+=item F<@ldap_conf@>
+
+LDAP configuration file
+
+=item F<@nsswitch_conf@>
+
+determines sudoers source order
+
+=item F<@netsvc_conf@>
+
+determines sudoers source order on AIX
+
+=back
+
+=head1 EXAMPLES
+
+=head2 Example ldap.conf
+
+  # Either specify one or more URIs or one or more host:port pairs.
+  # If neither is specified sudo will default to localhost, port 389.
+  #
+  #host          ldapserver
+  #host          ldapserver1 ldapserver2:390
+  #
+  # Default port if host is specified without one, defaults to 389.
+  #port          389
+  #
+  # URI will override the host and port settings.
+  uri            ldap://ldapserver
+  #uri            ldaps://secureldapserver
+  #uri            ldaps://secureldapserver ldap://ldapserver
+  #
+  # The amount of time, in seconds, to wait while trying to connect to
+  # an LDAP server.
+  bind_timelimit 30
+  #
+  # The amount of time, in seconds, to wait while performing an LDAP query.
+  timelimit 30
+  #
+  # Must be set or sudo will ignore LDAP; may be specified multiple times.
+  sudoers_base   ou=SUDOers,dc=example,dc=com
+  #
+  # verbose sudoers matching from ldap
+  #sudoers_debug 2
+  #
+  # Enable support for time-based entries in sudoers.
+  #sudoers_timed yes
+  #
+  # optional proxy credentials
+  #binddn        <who to search as>
+  #bindpw        <password>
+  #rootbinddn    <who to search as, uses /etc/ldap.secret for bindpw>
+  #
+  # LDAP protocol version, defaults to 3
+  #ldap_version 3
+  #
+  # Define if you want to use an encrypted LDAP connection.
+  # Typically, you must also set the port to 636 (ldaps).
+  #ssl on
+  #
+  # Define if you want to use port 389 and switch to
+  # encryption before the bind credentials are sent.
+  # Only supported by LDAP servers that support the start_tls
+  # extension such as OpenLDAP.
+  #ssl start_tls
+  #
+  # Additional TLS options follow that allow tweaking of the
+  # SSL/TLS connection.
+  #
+  #tls_checkpeer yes # verify server SSL certificate
+  #tls_checkpeer no  # ignore server SSL certificate
+  #
+  # If you enable tls_checkpeer, specify either tls_cacertfile
+  # or tls_cacertdir.  Only supported when using OpenLDAP.
+  #
+  #tls_cacertfile /etc/certs/trusted_signers.pem
+  #tls_cacertdir  /etc/certs
+  #
+  # For systems that don't have /dev/random
+  # use this along with PRNGD or EGD.pl to seed the
+  # random number pool to generate cryptographic session keys.
+  # Only supported when using OpenLDAP.
+  #
+  #tls_randfile /etc/egd-pool
+  #
+  # You may restrict which ciphers are used.  Consult your SSL
+  # documentation for which options go here.
+  # Only supported when using OpenLDAP.
+  #
+  #tls_ciphers <cipher-list>
+  #
+  # Sudo can provide a client certificate when communicating to
+  # the LDAP server.
+  # Tips:
+  #   * Enable both lines at the same time.
+  #   * Do not password protect the key file.
+  #   * Ensure the keyfile is only readable by root.
+  #
+  # For OpenLDAP:
+  #tls_cert /etc/certs/client_cert.pem
+  #tls_key  /etc/certs/client_key.pem
+  #
+  # For SunONE or iPlanet LDAP, tls_cert and tls_key may specify either
+  # a directory, in which case the files in the directory must have the
+  # default names (e.g. cert8.db and key4.db), or the path to the cert
+  # and key files themselves.  However, a bug in version 5.0 of the LDAP
+  # SDK will prevent specific file names from working.  For this reason
+  # it is suggested that tls_cert and tls_key be set to a directory,
+  # not a file name.
+  #
+  # The certificate database specified by tls_cert may contain CA certs
+  # and/or the client's cert.  If the client's cert is included, tls_key
+  # should be specified as well.
+  # For backward compatibility, "sslpath" may be used in place of tls_cert.
+  #tls_cert /var/ldap
+  #tls_key /var/ldap
+  #
+  # If using SASL authentication for LDAP (OpenSSL)
+  # use_sasl yes
+  # sasl_auth_id <SASL user name>
+  # rootuse_sasl yes
+  # rootsasl_auth_id <SASL user name for root access>
+  # sasl_secprops none
+  # krb5_ccname /etc/.ldapcache
+
+=head2 Sudo schema for OpenLDAP 
+
+The following schema, in OpenLDAP format, is included with B<sudo>
+source and binary distributions as F<schema.OpenLDAP>.  Simply copy
+it to the schema directory (e.g. F</etc/openldap/schema>), add the
+proper C<include> line in C<slapd.conf> and restart B<slapd>.
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.1
+    NAME 'sudoUser'
+    DESC 'User(s) who may  run sudo'
+    EQUALITY caseExactIA5Match
+    SUBSTR caseExactIA5SubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.2
+    NAME 'sudoHost'
+    DESC 'Host(s) who may run sudo'
+    EQUALITY caseExactIA5Match
+    SUBSTR caseExactIA5SubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.3
+    NAME 'sudoCommand'
+    DESC 'Command(s) to be executed by sudo'
+    EQUALITY caseExactIA5Match
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.4
+    NAME 'sudoRunAs'
+    DESC 'User(s) impersonated by sudo'
+    EQUALITY caseExactIA5Match
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.5
+    NAME 'sudoOption'
+    DESC 'Options(s) followed by sudo'
+    EQUALITY caseExactIA5Match
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.6
+    NAME 'sudoRunAsUser'
+    DESC 'User(s) impersonated by sudo'
+    EQUALITY caseExactIA5Match
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.7
+    NAME 'sudoRunAsGroup'
+    DESC 'Group(s) impersonated by sudo'
+    EQUALITY caseExactIA5Match
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.8
+    NAME 'sudoNotBefore'
+    DESC 'Start of time interval for which the entry is valid'
+    EQUALITY generalizedTimeMatch
+    ORDERING generalizedTimeOrderingMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ attributetype ( 1.3.6.1.4.1.15953.9.1.9
+    NAME 'sudoNotAfter'
+    DESC 'End of time interval for which the entry is valid'
+    EQUALITY generalizedTimeMatch
+    ORDERING generalizedTimeOrderingMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
+     NAME 'sudoOrder'
+     DESC 'an integer to order the sudoRole entries'
+     EQUALITY integerMatch
+     ORDERING integerOrderingMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
+    DESC 'Sudoer Entries'
+    MUST ( cn )
+    MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
+         sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
+         sudoOrder $ description )
+    )
+
+=head1 SEE ALSO
+
+L<ldap.conf(5)>, L<sudoers(5)>
+
+=head1 CAVEATS
+
+Note that there are differences in the way that LDAP-based I<sudoers>
+is parsed compared to file-based I<sudoers>.  See the L<Differences
+between LDAP and non-LDAP sudoers> section for more information.
+
+=head1 BUGS
+
+If you feel you have found a bug in B<sudo>, please submit a bug report
+at http://www.sudo.ws/sudo/bugs/
+
+=head1 SUPPORT
+
+Limited free support is available via the sudo-users mailing list,
+see http://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or
+search the archives.
+
+=head1 DISCLAIMER
+
+B<sudo> is provided ``AS IS'' and any express or implied warranties,
+including, but not limited to, the implied warranties of merchantability
+and fitness for a particular purpose are disclaimed.  See the LICENSE
+file distributed with B<sudo> or http://www.sudo.ws/sudo/license.html
+for complete details.