Manpages - sudoers.ldap.5

In addition to the standard

file,

may be configured via LDAP. This can be especially useful for synchronizing

in a large, distributed environment.

Using LDAP for

has several benefits:

no longer needs to read

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.

no longer exits if there is a typo in

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

from running.

It is possible to specify per-entry options that override the global default options.

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.

The

program is no longer needed.

provides locking and syntax checking of the

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.

The

configuration is contained in the

LDAP container.

Sudo first looks for the

entry in the SUDOers container. If found, the multi-valued

attribute is parsed in the same manner as a global

line in

In the following example, the

variable will be preserved in the environment for all users.

dn: cn=defaults,ou=SUDOers,dc=my-domain,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

It consists of the following attributes:

A user name, user-ID (prefixed with

Unix group name or ID (prefixed with

or

respectively), user netgroup (prefixed with

or non-Unix group name or ID (prefixed with

or

respectively). User netgroups are matched using the user and domain members only; the host member is not used when matching. Non-Unix group support is only available when an appropriate

is defined in the global

object.

A host name, IP address, IP network, or host netgroup (prefixed with a

The special value

will match any host. Host netgroups are matched using the host (both qualified and unqualified) and domain members only; the user member is not used when matching. If a

entry is preceded by an exclamation point,

and the entry matches, the

in which it resides will be ignored. Negated

entries are only supported by version 1.8.18 or higher.

A fully-qualified Unix command name with optional command line arguments, potentially including globbing characters (aka wild cards). If a command name is preceded by an exclamation point,

the user will be prohibited from running that command.

The built-in command

is used to permit a user to run

with the

option (or as

It may take command line arguments just as a normal command does. Note that

is a command built into

itself and must be specified in without a leading path.

The special value

will match any command.

If a command name is prefixed with a SHA-2 digest, it will only be allowed if the digest matches. This may be useful in situations where the user invoking

has write access to the command or its parent directory. The following digest formats are supported: sha224, sha256, sha384 and sha512. The digest name must be followed by a colon

and then the actual digest, in either hex or base64 format. For example, given the following value for sudoCommand:

sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls

The user may only run

if its sha224 digest matches the specified value. Command digests are only supported by version 1.8.7 or higher.

Identical in function to the global options described above, but specific to the

in which it resides.

A user name or uid (prefixed with

that commands may be run as or a Unix group (prefixed with a

or user netgroup (prefixed with a

that contains a list of users that commands may be run as. The special value

will match any user. If a

entry is preceded by an exclamation point,

and the entry matches, the

in which it resides will be ignored. If

is specified but empty, it will match the invoking user. If neither

nor

are present, the value of the

is used (defaults to

The

attribute is only available in

versions 1.7.0 and higher. Older versions of

use the

attribute instead. Negated

entries are only supported by version 1.8.26 or higher.

A Unix group or gid (prefixed with

that commands may be run as. The special value

will match any group. If a

entry is preceded by an exclamation point,

and the entry matches, the

in which it resides will be ignored.

The

attribute is only available in

versions 1.7.0 and higher. Negated

entries are only supported by version 1.8.26 or higher.

A timestamp in the form

that can be used to provide a start date/time for when the

will be valid. If multiple

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

attribute is only available in

versions 1.7.5 and higher and must be explicitly enabled via the

option in

A timestamp in the form

that indicates an expiration date/time, after which the

will no longer be valid. If multiple

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

attribute is only available in

versions 1.7.5 and higher and must be explicitly enabled via the

option in

The

entries retrieved from the LDAP directory have no inherent order. The

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 behavior of the sudoers file, where the order of the entries influences the result. If multiple entries match, the entry with the highest

attribute is chosen. This corresponds to the

behavior of the sudoers file. If the

attribute is not present, a value of 0 is assumed.

The

attribute is only available in

versions 1.7.5 and higher.

Each attribute listed above should contain a single value, but there may be multiple instances of each attribute type. A

must contain at least one

and

The following example allows users in group wheel to run any command on any host via

dn: cn=%wheel,ou=SUDOers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: %wheel sudoUser: %wheel sudoHost: ALL sudoCommand: ALL

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

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 other non-Unix groups and checks to see if the user belongs to any of them.

If timed entries are enabled with the

configuration directive, the LDAP queries include a sub-filter that limits retrieval to entries that satisfy the time constraints, if any.

If the

configuration directive is present (see

below), queries are performed to determine the list of netgroups the user belongs to before the sudoers query. This makes it possible to include netgroups in the sudoers query string in the same manner as Unix groups. The third query mentioned above is not performed unless a group provider plugin is also configured. The actual LDAP queries performed by

are as follows:

Match all

records with a

containing the user, host and NIS domain. The query will match

entries with either the short or long form of the host name or no host name specified in the tuple. If the NIS domain is set, the query will match only match entries that include the domain or for which there is no domain present. If the NIS domain is

set, a wildcard is used to match any domain name but be aware that the NIS schema used by some LDAP servers may not support wild cards for

Repeated queries are performed to find any nested

records with a

entry that refers to an already-matched record.

For sites with a large number of netgroups, using

can significantly speed up

execution time.

One of the major differences between LDAP and file-based

is that in LDAP,

Aliases are not supported.

For the most part, there is little need for

Aliases. Unix groups, non-Unix groups (via the

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 groups and netgroups can also be stored in LDAP there is no real need for

aliases.

There are also 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

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:

ALL,!/bin/sh # Always allows all commands because ALL is matched last puddles ALL=(root) !/bin/sh,ALL

cn=role1,ou=Sudoers,dc=my-domain,dc=com objectClass: sudoRole objectClass: top cn: role1 sudoUser: johnny sudoHost: ALL sudoCommand: ALL sudoCommand: !/bin/sh

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 it is not possible to use negation in a sudoUser, sudoRunAsUser or sudoRunAsGroup attribute. For example, the following attributes do not behave the way one might expect.

!joe

sudoUser: ALL sudoUser: !joe

The

utility can be used to convert between file-based and LDAP

However, there are features in the file-based sudoers that have no equivalent in LDAP-based sudoers (and vice versa). These cannot be converted automatically.

For example, a Cmnd_Alias in a

file may be converted to a

that contains multiple commands. Multiple users and/or groups may be assigned to the

Also, host, user, runas and command-based

entries are not supported. However, a

may contain one or more

attributes which can often serve the same purpose.

Consider the following

lines:

Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less Defaults!PAGERS noexec alice, bob ALL = ALL

In this example, alice and bob are allowed to run all commands, but the commands listed in PAGERS will have the noexec flag set, preventing shell escapes.

When converting this to LDAP, two sudoRole objects can be used:

dn: cn=PAGERS,ou=SUDOers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: PAGERS sudoUser: alice sudoUser: bob sudoHost: ALL sudoCommand: /usr/bin/more sudoCommand: /usr/bin/pg sudoCommand: /usr/bin/less sudoOption: noexec sudoOrder: 900

dn: cn=ADMINS,ou=SUDOers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: ADMINS sudoUser: alice sudoUser: bob sudoHost: ALL sudoCommand: ALL sudoOrder: 100

In the LDAP version, the sudoOrder attribute is used to guarantee that the PAGERS sudoRole with

has precedence. Unlike the

version, the LDAP version requires that all users for whom the restriction should apply be assigned to the PAGERS sudoRole. Using a Unix group or netgroup in PAGERS rather than listing each user would make this easier to maintain.

Per-user

entries can be emulated by using one or more sudoOption attributes in a sudoRole. Consider the following

lines:

User_Alias ADMINS = john, sally Defaults:ADMINS !authenticate ADMINS ALL = (ALL:ALL) ALL

In this example, john and sally are allowed to run any command as any user or group.

When converting this to LDAP, we can use a Unix group instead of the User_Alias.

dn: cn=admins,ou=SUDOers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: admins sudoUser: %admin sudoHost: ALL sudoRunAsUser: ALL sudoRunAsGroup: ALL sudoCommand: ALL sudoOption: !authenticate

This assumes that users john and sally are members of the

Unix group.

In order to use

LDAP support, the

schema must be installed on your LDAP server. In addition, be sure to index the

attribute.

The

distribution includes versions of the

schema for multiple LDAP servers:

OpenLDAP slapd and

ldapd

OpenLDAP slapd 2.3 and higher when on-line configuration is enabled

Netscape-derived servers such as the iPlanet, Oracle, and 389 Directory Servers

Microsoft Active Directory

The schema in OpenLDAP format is also included in the

section.

Sudo reads the

file for LDAP-specific configuration. Typically, this file is shared between different LDAP-aware clients. As such, most of the settings are not

Note that

parses

itself and may support options that differ from those described in the system’s

manual. The path to

may be overridden via the

plugin argument in

Also note that on systems using the OpenLDAP libraries, default values specified in

or the user’s

files are not used.

supports a variety of LDAP library implementations, including OpenLDAP, Netscape-derived (also used by Solaris and HP-UX), and IBM LDAP (aka Tivoli). Some options are specific to certain LDAP implementations or have implementation-specific behavior. These differences are noted below where applicable.

Only those options explicitly listed in

as being supported by

are honored. Configuration options are listed below in upper case but are parsed in a case-independent manner.

Lines beginning with a pound sign

are ignored. Leading white space is removed from the beginning of lines.

The

parameter specifies the amount of time, in seconds, to wait while trying to connect to an LDAP server. If multiple

or

are specified, this is the amount of time to wait before trying the next one in the list.

The

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.

The

parameter specifies the password to use when performing LDAP operations. This is typically used in conjunction with the

parameter. The

may be a plain text password or a base64-encoded string with a

prefix. For example:

BINDPW base64:dGVzdA==

If a plain text password is used, it should be a simple string without quotes. Plain text passwords may not include the comment character

and the escaping of special characters with a backslash

is not supported.

How alias dereferencing is to be performed when searching. See the

manual for a full description of this option.

If no

is specified (see below), the

parameter specifies a white space-delimited list of LDAP servers to connect to. Each host may include an optional

separated by a colon

The

parameter is deprecated in favor of the

specification and is included for backward compatibility only.

The path to the Kerberos 5 credential cache to use when authenticating with the remote server.

This option is only relevant when using SASL authentication (see below).

The version of the LDAP protocol to use when connecting to the server. The default value is protocol version 3.

The base DN to use when performing LDAP netgroup queries. Typically this is of the form

for the domain

Multiple

lines may be specified, in which case they are queried in the order specified.

This option can be used to query a user’s netgroups directly via LDAP which is usually faster than fetching every

object containing a

that begins with a

prefix. The NIS schema used by some LDAP servers need a modification to support querying the

object by its

member. OpenLDAP’s

requires the following change to the

attribute:

attributetype ( 1.3.6.1.1.1.1.14 NAME ’nisNetgroupTriple’ DESC ’Netgroup triple’ EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

An LDAP filter which is used to restrict the set of records returned when performing an LDAP netgroup query. Typically, this is of the form

or

The default search filter is:

If

is omitted, no search filter will be used.

This option is only used when querying netgroups directly via LDAP.

An alias for

provided for OpenLDAP compatibility.

If no

is specified, the

parameter specifies the default port to connect to on the LDAP server if a

parameter does not specify the port itself. If no

parameter is used, the default is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The

parameter is deprecated in favor of the

specification and is included for backward compatibility only.

The

parameter specifies the identity, in the form of a Distinguished Name (DN), to use when performing privileged LDAP operations, such as

queries. The password corresponding to the identity should be stored in the or the path specified by the

plugin argument in

which defaults to

If no

is specified, the

identity is used (if any).

Enable

to enable SASL authentication when connecting to an LDAP server from a privileged process, such as

The SASL user name to use when connecting to the LDAP server. By default,

will use an anonymous connection.

This option is only relevant when using SASL authentication.

A white space-delimited list of SASL authentication mechanisms to use. By default,

will use

authentication.

SASL security properties or

for no properties. See the SASL programmer’s manual for details.

This option is only relevant when using SASL authentication.

If the

parameter is set to

TLS (SSL) encryption is always used when communicating with the LDAP server. Typically, this involves connecting to the server on port 636 (ldaps).

If the

parameter is set to

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

extension, such as the OpenLDAP and IBM Tivoli Directory servers.

The base DN to use when performing

LDAP queries. Typically this is of the form

for the domain

Multiple

lines may be specified, in which case they are queried in the order specified.

This sets the debug level for

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.

The

parameter is deprecated and will be removed in a future release. The same information is now logged via the

debugging framework using the

subsystem at priorities

and

for

values 1 and 2 respectively. See the

manual for details on how to configure

debugging.

An LDAP filter which is used to restrict the set of records returned when performing a

LDAP query. Typically, this is of the form

or

The default search filter is:

If

is omitted, no search filter will be used.

Whether or not to evaluate the

and

attributes that implement time-dependent sudoers entries.

The

parameter specifies the amount of time, in seconds, to wait for a response to an LDAP query.

The

parameter specifies the amount of time, in seconds, to wait for a response from the various LDAP APIs.

An alias for

for OpenLDAP compatibility.

The path to a certificate authority bundle which contains the certificates for all the Certificate Authorities the client knows to be valid, e.g.,

This option is only supported by the OpenLDAP libraries. Netscape-derived LDAP libraries use the same certificate database for CA and client certificates (see

Similar to

but instead of a file, it is a directory containing individual Certificate Authority certificates, e.g.,

The directory specified by

is checked after

This option is only supported by the OpenLDAP libraries.

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.

Unused, the key database specified by

contains both keys and certificates.

When using Netscape-derived libraries, this file may also contain Certificate Authority certificates.

If enabled,

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),

will be unable to connect to it. If

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.

This option is not supported by the IBM LDAP libraries.

The path to a file containing the private key which matches the certificate specified by

The private key must not be password-protected. The key type depends on the LDAP libraries used.

When using IBM LDAP libraries, this file may also contain Certificate Authority and client certificates and may be encrypted.

The

parameter allows the administer to restrict which encryption algorithms may be used for TLS (SSL) connections. See the OpenLDAP or IBM Tivoli Directory Server manual for a list of valid ciphers.

This option is not supported by Netscape-derived libraries.

The

contains the password used to decrypt the key database on clients using the IBM LDAP library. The

may be a plain text password or a base64-encoded string with a

prefix. For example:

TLS_KEYPW base64:dGVzdA==

If a plain text password is used, it should be a simple string without quotes. Plain text passwords may not include the comment character

and the escaping of special characters with a backslash

is not supported. If this option is used,

must not be world-readable to avoid exposing the password. Alternately, a

can be used to store the password in encrypted form (see below).

If no

is specified, a

will be used if it exists. The

must have the same path as the file specified by

but use a

file extension instead of

e.g.,

The default

that ships with the IBM Tivoli Directory Server is encrypted with the password

The

utility can be used to manage the key database and create a

This option is only supported by the IBM LDAP libraries.

The

parameter controls how the LDAP server’s TLS certificated will be verified (if at all). If the server’s TLS certificate cannot be verified (usually because it is signed by an unknown certificate authority),

will be unable to connect to it. The following

values are supported:

The server certificate will not be requested or checked.

The server certificate will be requested. A missing or invalid certificate is ignored and not considered an error.

The server certificate will be requested. A missing certificate is ignored but an invalid certificate will result in a connection error.

The server certificate will be requested. A missing or invalid certificate will result in a connection error. This is the default behavior.

This option is only supported by the OpenLDAP libraries. Other LDAP libraries only support the

parameter.

The

parameter specifies the path to an entropy source for systems that lack a random device. It is generally used in conjunction with

or

This option is only supported by the OpenLDAP libraries.

Specifies a white space-delimited list of one or more URIs describing the LDAP server(s) to connect to. The

may be either

the latter being for servers that support TLS (SSL) encryption. If no

is specified, the default is port 389 for

or port 636 for

If no

is specified,

will connect to

Multiple

lines are treated identically to a

line containing multiple entries. Only systems using the OpenSSL libraries support the mixing of

and

URIs. Both the Netscape-derived and IBM LDAP libraries used on most commercial versions of Unix are only capable of supporting one or the other.

Enable

for LDAP servers that support SASL authentication.

The SASL user name to use when

is enabled.

See the

entry in the

section.

Unless it is disabled at build time,

consults the Name Service Switch file,

to specify the

search order. Sudo looks for a line beginning with

and uses this to determine the search order. Note that by default,

does not stop searching after the first match and later matches take precedence over earlier ones (unless

is used, see below). The following sources are recognized:

read sudoers from

read sudoers from LDAP

In addition, a subset of

action statements is supported, specifically

and

These will unconditionally terminate the search if the user was either found

or not found

in the immediately preceding source. Other action statements tokens are not supported, nor is test negation with

To consult LDAP first followed by the local sudoers file (if it exists), use:

sudoers: ldap files

To consult LDAP only when no match is found in the local sudoers file (if it exists), use:

sudoers: files [SUCCESS=return] ldap

The local

file can be ignored completely by using:

sudoers: ldap

If the

file is not present or there is no sudoers line, the following default is assumed:

sudoers: files

Note that

is supported even when the underlying operating system does not use an nsswitch.conf file, except on AIX (see below).

On AIX systems, the

file is consulted instead of

simply treats

as a variant of

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

file can be ignored completely by using:

sudoers = ldap

To treat LDAP as authoritative 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

qualifier only affects user lookups; both LDAP and

will be queried for

entries.

If the

file is not present or there is no sudoers line, the following default is assumed:

sudoers = files

On systems with the

(SSSD) and where

has been built with SSSD support, it is possible to use SSSD to cache LDAP

rules. To use SSSD as the

source, you should use

instead of

for the sudoers entry in

Note that the

file is not used by the SSSD

back end. Please see

for more information on configuring

to work with SSSD.

LDAP configuration file

determines sudoers source order

determines sudoers source order on AIX

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

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=my-domain,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

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. #