diff options
Diffstat (limited to 'doc/sudoers.ldap.cat')
| -rw-r--r-- | doc/sudoers.ldap.cat | 1033 |
1 files changed, 1033 insertions, 0 deletions
diff --git a/doc/sudoers.ldap.cat b/doc/sudoers.ldap.cat new file mode 100644 index 0000000..0d48b9a --- /dev/null +++ b/doc/sudoers.ldap.cat @@ -0,0 +1,1033 @@ +SUDOERS.LDAP(4) File Formats Manual SUDOERS.LDAP(4) + +NNAAMMEE + ssuuddooeerrss..llddaapp - sudo LDAP configuration + +DDEESSCCRRIIPPTTIIOONN + In addition to the standard _s_u_d_o_e_r_s file, ssuuddoo may be configured via + LDAP. This can be especially useful for synchronizing _s_u_d_o_e_r_s in a + large, distributed environment. + + Using LDAP for _s_u_d_o_e_r_s has several benefits: + + ++oo ssuuddoo no longer needs to read _s_u_d_o_e_r_s 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. + + ++oo ssuuddoo no longer exits if there is a typo in _s_u_d_o_e_r_s. 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 ssuuddoo from running. + + ++oo It is possible to specify per-entry options that override the global + default options. _/_e_t_c_/_s_u_d_o_e_r_s 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. + + ++oo The vviissuuddoo program is no longer needed. vviissuuddoo provides locking and + syntax checking of the _/_e_t_c_/_s_u_d_o_e_r_s 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. + + SSUUDDOOeerrss LLDDAAPP ccoonnttaaiinneerr + The _s_u_d_o_e_r_s configuration is contained in the ou=SUDOers LDAP container. + + Sudo first looks for the cn=defaults entry in the SUDOers container. If + found, the multi-valued sudoOption attribute is parsed in the same manner + as a global Defaults line in _/_e_t_c_/_s_u_d_o_e_r_s. In the following example, the + SSH_AUTH_SOCK 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 sudoRole. It consists of the + following attributes: + + ssuuddooUUsseerr + 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 + _g_r_o_u_p___p_l_u_g_i_n is defined in the global _d_e_f_a_u_l_t_s sudoRole object. + + ssuuddooHHoosstt + A host name, IP address, IP network, or host netgroup (prefixed + with a `+'). The special value ALL 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 sudoHost entry is preceded by an exclamation + point, `!', and the entry matches, the sudoRole in which it resides + will be ignored. Negated sudoHost entries are only supported by + version 1.8.18 or higher. + + ssuuddooCCoommmmaanndd + 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 "sudoedit" is used to permit a user to run + ssuuddoo with the --ee option (or as ssuuddooeeddiitt). It may take command line + arguments just as a normal command does. Note that "sudoedit" is a + command built into ssuuddoo itself and must be specified in without a + leading path. + + The special value ALL 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 ssuuddoo 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 _/_b_i_n_/_l_s if its sha224 digest matches the + specified value. Command digests are only supported by version + 1.8.7 or higher. + + ssuuddooOOppttiioonn + Identical in function to the global options described above, but + specific to the sudoRole in which it resides. + + ssuuddooRRuunnAAssUUsseerr + 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 ALL will match any user. If a sudoRunAsUser + entry is preceded by an exclamation point, `!', and the entry + matches, the sudoRole in which it resides will be ignored. If + sudoRunAsUser is specified but empty, it will match the invoking + user. If neither sudoRunAsUser nor sudoRunAsGroup are present, the + value of the _r_u_n_a_s___d_e_f_a_u_l_t sudoOption is used (defaults to root). + + The sudoRunAsUser attribute is only available in ssuuddoo versions + 1.7.0 and higher. Older versions of ssuuddoo use the sudoRunAs + attribute instead. Negated sudoRunAsUser entries are only + supported by version 1.8.26 or higher. + + ssuuddooRRuunnAAssGGrroouupp + A Unix group or gid (prefixed with `#') that commands may be run + as. The special value ALL will match any group. If a + sudoRunAsGroup entry is preceded by an exclamation point, `!', and + the entry matches, the sudoRole in which it resides will be + ignored. + + The sudoRunAsGroup attribute is only available in ssuuddoo versions + 1.7.0 and higher. Negated sudoRunAsGroup entries are only + supported by version 1.8.26 or higher. + + ssuuddooNNoottBBeeffoorree + A timestamp in the form yyyymmddHHMMSSZ that can be used to provide + a start date/time for when the sudoRole will be valid. If multiple + 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 sudoNotBefore attribute is only available in ssuuddoo versions + 1.7.5 and higher and must be explicitly enabled via the + SSUUDDOOEERRSS__TTIIMMEEDD option in _/_e_t_c_/_l_d_a_p_._c_o_n_f. + + ssuuddooNNoottAAfftteerr + A timestamp in the form yyyymmddHHMMSSZ that indicates an + expiration date/time, after which the sudoRole will no longer be + valid. If multiple sudoNotAfter 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 sudoNotAfter attribute is only available in ssuuddoo versions 1.7.5 + and higher and must be explicitly enabled via the SSUUDDOOEERRSS__TTIIMMEEDD + option in _/_e_t_c_/_l_d_a_p_._c_o_n_f. + + ssuuddooOOrrddeerr + The sudoRole entries retrieved from the LDAP directory have no + inherent order. The 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 behavior of the sudoers file, where the + order of the entries influences the result. If multiple entries + match, the entry with the highest sudoOrder attribute is chosen. + This corresponds to the "last match" behavior of the sudoers file. + If the sudoOrder attribute is not present, a value of 0 is assumed. + + The sudoOrder attribute is only available in ssuuddoo 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 sudoRole must contain at + least one sudoUser, sudoHost and sudoCommand. + + The following example allows users in group wheel to run any command on + any host via ssuuddoo: + + dn: cn=%wheel,ou=SUDOers,dc=my-domain,dc=com + objectClass: top + objectClass: sudoRole + cn: %wheel + sudoUser: %wheel + sudoHost: ALL + sudoCommand: ALL + + AAnnaattoommyy ooff LLDDAAPP ssuuddooeerrss llooookkuupp + 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 other non-Unix groups + and checks to see if the user belongs to any of them. + + If timed entries are enabled with the SSUUDDOOEERRSS__TTIIMMEEDD configuration + directive, the LDAP queries include a sub-filter that limits retrieval to + entries that satisfy the time constraints, if any. + + If the NNEETTGGRROOUUPP__BBAASSEE configuration directive is present (see _C_o_n_f_i_g_u_r_i_n_g + _l_d_a_p_._c_o_n_f 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 ssuuddoo are as follows: + + 1. Match all nisNetgroup records with a nisNetgroupTriple containing + the user, host and NIS domain. The query will match + nisNetgroupTriple 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 _n_o_t 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 nisNetgroupTriple. + + 2. Repeated queries are performed to find any nested nisNetgroup + records with a memberNisNetgroup entry that refers to an already- + matched record. + + For sites with a large number of netgroups, using NNEETTGGRROOUUPP__BBAASSEE can + significantly speed up ssuuddoo's execution time. + + DDiiffffeerreenncceess bbeettwweeeenn LLDDAAPP aanndd nnoonn--LLDDAAPP ssuuddooeerrss + One of the major differences between LDAP and file-based _s_u_d_o_e_r_s is that + in LDAP, ssuuddoo-specific Aliases are not supported. + + For the most part, there is little need for ssuuddoo-specific Aliases. Unix + groups, non-Unix groups (via the _g_r_o_u_p___p_l_u_g_i_n) 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 ssuuddoo-specific 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 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 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. + + # 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 + + CCoonnvveerrttiinngg bbeettwweeeenn ffiillee--bbaasseedd aanndd LLDDAAPP ssuuddooeerrss + The cvtsudoers(1) utility can be used to convert between file-based and + LDAP _s_u_d_o_e_r_s. 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 _s_u_d_o_e_r_s file may be converted to a + sudoRole that contains multiple commands. Multiple users and/or groups + may be assigned to the sudoRole. + + Also, host, user, runas and command-based Defaults entries are not + supported. However, a sudoRole may contain one or more sudoOption + attributes which can often serve the same purpose. + + Consider the following _s_u_d_o_e_r_s 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 _n_o_e_x_e_c has precedence. Unlike the _s_u_d_o_e_r_s + 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 Defaults entries can be emulated by using one or more sudoOption + attributes in a sudoRole. Consider the following _s_u_d_o_e_r_s 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 "admins" Unix + group. + + SSuuddooeerrss sscchheemmaa + In order to use ssuuddoo's LDAP support, the ssuuddoo schema must be installed on + your LDAP server. In addition, be sure to index the sudoUser attribute. + + The ssuuddoo distribution includes versions of the ssuuddooeerrss schema for + multiple LDAP servers: + + _s_c_h_e_m_a_._O_p_e_n_L_D_A_P + OpenLDAP slapd and OpenBSD ldapd + + _s_c_h_e_m_a_._o_l_c_S_u_d_o + OpenLDAP slapd 2.3 and higher when on-line configuration is enabled + + _s_c_h_e_m_a_._i_P_l_a_n_e_t + Netscape-derived servers such as the iPlanet, Oracle, and 389 + Directory Servers + + _s_c_h_e_m_a_._A_c_t_i_v_e_D_i_r_e_c_t_o_r_y + Microsoft Active Directory + + The schema in OpenLDAP format is also included in the _E_X_A_M_P_L_E_S section. + + CCoonnffiigguurriinngg llddaapp..ccoonnff + Sudo reads the _/_e_t_c_/_l_d_a_p_._c_o_n_f file for LDAP-specific configuration. + Typically, this file is shared between different LDAP-aware clients. As + such, most of the settings are not ssuuddoo-specific. Note that ssuuddoo parses + _/_e_t_c_/_l_d_a_p_._c_o_n_f itself and may support options that differ from those + described in the system's ldap.conf(4) manual. The path to _l_d_a_p_._c_o_n_f may + be overridden via the _l_d_a_p___c_o_n_f plugin argument in sudo.conf(4). + + Also note that on systems using the OpenLDAP libraries, default values + specified in _/_e_t_c_/_o_p_e_n_l_d_a_p_/_l_d_a_p_._c_o_n_f or the user's _._l_d_a_p_r_c files are not + used. + + Only those options explicitly listed in _/_e_t_c_/_l_d_a_p_._c_o_n_f as being supported + by ssuuddoo 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. + + BBIINNDD__TTIIMMEELLIIMMIITT _s_e_c_o_n_d_s + The BBIINNDD__TTIIMMEELLIIMMIITT parameter specifies the amount of time, in + seconds, to wait while trying to connect to an LDAP server. If + multiple UURRIIs or HHOOSSTTs are specified, this is the amount of time to + wait before trying the next one in the list. + + BBIINNDDDDNN _D_N + The BBIINNDDDDNN 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. + + BBIINNDDPPWW _s_e_c_r_e_t + The BBIINNDDPPWW parameter specifies the password to use when performing + LDAP operations. This is typically used in conjunction with the + BBIINNDDDDNN parameter. The _s_e_c_r_e_t may be a plain text password or a + base64-encoded string with a "base64:" 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. + + DDEERREEFF _n_e_v_e_r_/_s_e_a_r_c_h_i_n_g_/_f_i_n_d_i_n_g_/_a_l_w_a_y_s + How alias dereferencing is to be performed when searching. See the + ldap.conf(4) manual for a full description of this option. + + HHOOSSTT _n_a_m_e_[_:_p_o_r_t_] _._._. + If no UURRII is specified (see below), the HHOOSSTT parameter specifies a + white space-delimited list of LDAP servers to connect to. Each + host may include an optional _p_o_r_t separated by a colon (`:'). The + HHOOSSTT parameter is deprecated in favor of the UURRII specification and + is included for backwards compatibility only. + + KKRRBB55__CCCCNNAAMMEE _f_i_l_e _n_a_m_e + 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). + + LLDDAAPP__VVEERRSSIIOONN _n_u_m_b_e_r + The version of the LDAP protocol to use when connecting to the + server. The default value is protocol version 3. + + NNEETTGGRROOUUPP__BBAASSEE _b_a_s_e + The base DN to use when performing LDAP netgroup queries. + Typically this is of the form ou=netgroup,dc=my-domain,dc=com for + the domain my-domain.com. Multiple NNEETTGGRROOUUPP__BBAASSEE 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 sudoRole object + containing a sudoUser that begins with a `+' prefix. The NIS + schema used by some LDAP servers need a modification to support + querying the nisNetgroup object by its nisNetgroupTriple member. + OpenLDAP's ssllaappdd requires the following change to the + nisNetgroupTriple 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 ) + + NNEETTGGRROOUUPP__SSEEAARRCCHH__FFIILLTTEERR _l_d_a_p___f_i_l_t_e_r + 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 attribute=value or + (&(attribute=value)(attribute2=value2)). The default search filter + is: objectClass=nisNetgroup. If _l_d_a_p___f_i_l_t_e_r is omitted, no search + filter will be used. This option is only when querying netgroups + directly via LDAP. + + NNEETTWWOORRKK__TTIIMMEEOOUUTT _s_e_c_o_n_d_s + An alias for BBIINNDD__TTIIMMEELLIIMMIITT provided for OpenLDAP compatibility. + + PPOORRTT _p_o_r_t___n_u_m_b_e_r + If no UURRII is specified, the PPOORRTT parameter specifies the default + port to connect to on the LDAP server if a HHOOSSTT parameter does not + specify the port itself. If no PPOORRTT parameter is used, the default + is port 389 for LDAP and port 636 for LDAP over TLS (SSL). The + PPOORRTT parameter is deprecated in favor of the UURRII specification and + is included for backwards compatibility only. + + RROOOOTTBBIINNDDDDNN _D_N + The RROOOOTTBBIINNDDDDNN parameter specifies the identity, in the form of a + Distinguished Name (DN), to use when performing privileged LDAP + operations, such as _s_u_d_o_e_r_s queries. The password corresponding to + the identity should be stored in the or the path specified by the + _l_d_a_p___s_e_c_r_e_t plugin argument in sudo.conf(4), which defaults to + _/_e_t_c_/_l_d_a_p_._s_e_c_r_e_t. If no RROOOOTTBBIINNDDDDNN is specified, the BBIINNDDDDNN + identity is used (if any). + + RROOOOTTUUSSEE__SSAASSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o + Enable RROOOOTTUUSSEE__SSAASSLL to enable SASL authentication when connecting + to an LDAP server from a privileged process, such as ssuuddoo. + + SSAASSLL__AAUUTTHH__IIDD _i_d_e_n_t_i_t_y + The SASL user name to use when connecting to the LDAP server. By + default, ssuuddoo will use an anonymous connection. This option is + only relevant when using SASL authentication. + + SSAASSLL__MMEECCHH _m_e_c_h_a_n_i_s_m_s + A white space-delimited list of SASL authentication mechanisms to + use. By default, ssuuddoo will use GSSAPI authentication. + + SSAASSLL__SSEECCPPRROOPPSS _n_o_n_e_/_p_r_o_p_e_r_t_i_e_s + SASL security properties or _n_o_n_e for no properties. See the SASL + programmer's manual for details. This option is only relevant when + using SASL authentication. + + SSSSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o + If the SSSSLL parameter is set to on, true or yes, TLS (SSL) + encryption is always used when communicating with the LDAP server. + Typically, this involves connecting to the server on port 636 + (ldaps). + + SSSSLL _s_t_a_r_t___t_l_s + If the SSSSLL parameter is set to 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 + _s_t_a_r_t___t_l_s extension, such as the OpenLDAP and Tivoli Directory + servers. + + SSUUDDOOEERRSS__BBAASSEE _b_a_s_e + The base DN to use when performing ssuuddoo LDAP queries. Typically + this is of the form ou=SUDOers,dc=my-domain,dc=com for the domain + my-domain.com. Multiple SSUUDDOOEERRSS__BBAASSEE lines may be specified, in + which case they are queried in the order specified. + + SSUUDDOOEERRSS__DDEEBBUUGG _d_e_b_u_g___l_e_v_e_l + This sets the debug level for ssuuddoo 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 SSUUDDOOEERRSS__DDEEBBUUGG parameter is deprecated and will be removed in a + future release. The same information is now logged via the ssuuddoo + debugging framework using the "ldap" subsystem at priorities _d_i_a_g + and _i_n_f_o for _d_e_b_u_g___l_e_v_e_l values 1 and 2 respectively. See the + sudo.conf(4) manual for details on how to configure ssuuddoo debugging. + + SSUUDDOOEERRSS__SSEEAARRCCHH__FFIILLTTEERR _l_d_a_p___f_i_l_t_e_r + An LDAP filter which is used to restrict the set of records + returned when performing a ssuuddoo LDAP query. Typically, this is of + the form attribute=value or + (&(attribute=value)(attribute2=value2)). The default search filter + is: objectClass=sudoRole. If _l_d_a_p___f_i_l_t_e_r is omitted, no search + filter will be used. + + SSUUDDOOEERRSS__TTIIMMEEDD _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o + Whether or not to evaluate the sudoNotBefore and sudoNotAfter + attributes that implement time-dependent sudoers entries. + + TTIIMMEELLIIMMIITT _s_e_c_o_n_d_s + The TTIIMMEELLIIMMIITT parameter specifies the amount of time, in seconds, + to wait for a response to an LDAP query. + + TTIIMMEEOOUUTT _s_e_c_o_n_d_s + The TTIIMMEEOOUUTT parameter specifies the amount of time, in seconds, to + wait for a response from the various LDAP APIs. + + TTLLSS__CCAACCEERRTT _f_i_l_e _n_a_m_e + An alias for TTLLSS__CCAACCEERRTTFFIILLEE for OpenLDAP compatibility. + + TTLLSS__CCAACCEERRTTFFIILLEE _f_i_l_e _n_a_m_e + The path to a certificate authority bundle which contains the + certificates for all the Certificate Authorities the client knows + to be valid, e.g., _/_e_t_c_/_s_s_l_/_c_a_-_b_u_n_d_l_e_._p_e_m. This option is only + supported by the OpenLDAP libraries. Netscape-derived LDAP + libraries use the same certificate database for CA and client + certificates (see TTLLSS__CCEERRTT). + + TTLLSS__CCAACCEERRTTDDIIRR _d_i_r_e_c_t_o_r_y + Similar to TTLLSS__CCAACCEERRTTFFIILLEE but instead of a file, it is a directory + containing individual Certificate Authority certificates, e.g., + _/_e_t_c_/_s_s_l_/_c_e_r_t_s. The directory specified by TTLLSS__CCAACCEERRTTDDIIRR is + checked after TTLLSS__CCAACCEERRTTFFIILLEE. This option is only supported by the + OpenLDAP libraries. + + TTLLSS__CCEERRTT _f_i_l_e _n_a_m_e + 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: + tls_cert /etc/ssl/client_cert.pem + + Netscape-derived: + tls_cert /var/ldap/cert7.db + + Tivoli Directory Server: + Unused, the key database specified by TTLLSS__KKEEYY contains both + keys and certificates. + + When using Netscape-derived libraries, this file may also + contain Certificate Authority certificates. + + TTLLSS__CCHHEECCKKPPEEEERR _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o + If enabled, TTLLSS__CCHHEECCKKPPEEEERR 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), ssuuddoo will be unable to connect to it. If + TTLLSS__CCHHEECCKKPPEEEERR 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 Tivoli + Directory Server LDAP libraries. + + TTLLSS__KKEEYY _f_i_l_e _n_a_m_e + The path to a file containing the private key which matches the + certificate specified by TTLLSS__CCEERRTT. The private key must not be + password-protected. The key type depends on the LDAP libraries + used. + + OpenLDAP: + tls_key /etc/ssl/client_key.pem + + Netscape-derived: + tls_key /var/ldap/key3.db + + Tivoli Directory Server: + tls_key /usr/ldap/ldapkey.kdb + When using Tivoli LDAP libraries, this file may also contain + Certificate Authority and client certificates and may be encrypted. + + TTLLSS__CCIIPPHHEERRSS _c_i_p_h_e_r _l_i_s_t + The TTLLSS__CCIIPPHHEERRSS parameter allows the administer to restrict which + encryption algorithms may be used for TLS (SSL) connections. See + the OpenLDAP or Tivoli Directory Server manual for a list of valid + ciphers. This option is not supported by Netscape-derived + libraries. + + TTLLSS__KKEEYYPPWW _s_e_c_r_e_t + The TTLLSS__KKEEYYPPWW contains the password used to decrypt the key + database on clients using the Tivoli Directory Server LDAP library. + The _s_e_c_r_e_t may be a plain text password or a base64-encoded string + with a "base64:" 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, + _/_e_t_c_/_l_d_a_p_._c_o_n_f must not be world-readable to avoid exposing the + password. Alternately, a _s_t_a_s_h _f_i_l_e can be used to store the + password in encrypted form (see below). + + If no TTLLSS__KKEEYYPPWW is specified, a _s_t_a_s_h _f_i_l_e will be used if it + exists. The _s_t_a_s_h _f_i_l_e must have the same path as the file + specified by TTLLSS__KKEEYY, but use a .sth file extension instead of + .kdb, e.g., ldapkey.sth. The default ldapkey.kdb that ships with + Tivoli Directory Server is encrypted with the password + ssl_password. The _g_s_k_8_c_a_p_i_c_m_d utility can be used to manage the + key database and create a _s_t_a_s_h _f_i_l_e. This option is only + supported by the Tivoli LDAP libraries. + + TTLLSS__RREEQQCCEERRTT _l_e_v_e_l + The TTLLSS__RREEQQCCEERRTT 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), ssuuddoo will be unable to connect to + it. The following _l_e_v_e_l values are supported: + + never The server certificate will not be requested or + checked. + + allow The server certificate will be requested. A missing + or invalid certificate is ignored and not considered + an error. + + try The server certificate will be requested. A missing + certificate is ignored but an invalid certificate + will result in a connection error. + + demand | _h_a_r_d + 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 TTLLSS__CCHHEECCKKPPEEEERR parameter. + + TTLLSS__RRAANNDDFFIILLEE _f_i_l_e _n_a_m_e + The TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an entropy source + for systems that lack a random device. It is generally used in + conjunction with _p_r_n_g_d or _e_g_d. This option is only supported by + the OpenLDAP libraries. + + UURRII _l_d_a_p_[_s_]_:_/_/_[_h_o_s_t_n_a_m_e_[_:_p_o_r_t_]_] _._._. + Specifies a white space-delimited list of one or more URIs + describing the LDAP server(s) to connect to. The _p_r_o_t_o_c_o_l may be + either _l_d_a_p _l_d_a_p_s, the latter being for servers that support TLS + (SSL) encryption. If no _p_o_r_t is specified, the default is port 389 + for ldap:// or port 636 for ldaps://. If no _h_o_s_t_n_a_m_e is specified, + ssuuddoo will connect to _l_o_c_a_l_h_o_s_t. Multiple UURRII lines are treated + identically to a UURRII line containing multiple entries. Only + systems using the OpenSSL libraries support the mixing of ldap:// + and ldaps:// URIs. Both the Netscape-derived and Tivoli LDAP + libraries used on most commercial versions of Unix are only capable + of supporting one or the other. + + UUSSEE__SSAASSLL _o_n_/_t_r_u_e_/_y_e_s_/_o_f_f_/_f_a_l_s_e_/_n_o + Enable UUSSEE__SSAASSLL for LDAP servers that support SASL authentication. + + RROOOOTTSSAASSLL__AAUUTTHH__IIDD _i_d_e_n_t_i_t_y + The SASL user name to use when RROOOOTTUUSSEE__SSAASSLL is enabled. + + See the _l_d_a_p_._c_o_n_f entry in the _E_X_A_M_P_L_E_S section. + + CCoonnffiigguurriinngg nnsssswwiittcchh..ccoonnff + Unless it is disabled at build time, ssuuddoo consults the Name Service + Switch file, _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f, to specify the _s_u_d_o_e_r_s search order. + Sudo looks for a line beginning with sudoers: and uses this to determine + the search order. Note that ssuuddoo 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 _/_e_t_c_/_s_u_d_o_e_r_s + ldap read sudoers from LDAP + + In addition, the entry [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 _s_u_d_o_e_r_s file can be ignored completely by using: + + sudoers: ldap + + If the _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f file is not present or there is no sudoers + line, the following default is assumed: + + sudoers: files + + Note that _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f is supported even when the underlying + operating system does not use an nsswitch.conf file, except on AIX (see + below). + + CCoonnffiigguurriinngg nneettssvvcc..ccoonnff + On AIX systems, the _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f file is consulted instead of + _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f. ssuuddoo simply treats _n_e_t_s_v_c_._c_o_n_f as a variant of + _n_s_s_w_i_t_c_h_._c_o_n_f; 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 _s_u_d_o_e_r_s 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 auth qualifier only affects user + lookups; both LDAP and _s_u_d_o_e_r_s will be queried for Defaults entries. + + If the _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f file is not present or there is no sudoers line, + the following default is assumed: + + sudoers = files + + IInntteeggrraattiioonn wwiitthh ssssssdd + On systems with the _S_y_s_t_e_m _S_e_c_u_r_i_t_y _S_e_r_v_i_c_e_s _D_a_e_m_o_n (SSSD) and where ssuuddoo + has been built with SSSD support, it is possible to use SSSD to cache + LDAP _s_u_d_o_e_r_s rules. To use SSSD as the _s_u_d_o_e_r_s source, you should use + sssd instead of ldap for the sudoers entry in _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f. Note + that the _/_e_t_c_/_l_d_a_p_._c_o_n_f file is not used by the SSSD ssuuddoo back end. + Please see sssd-sudo(4) for more information on configuring ssuuddoo to work + with SSSD. + +FFIILLEESS + _/_e_t_c_/_l_d_a_p_._c_o_n_f LDAP configuration file + + _/_e_t_c_/_n_s_s_w_i_t_c_h_._c_o_n_f determines sudoers source order + + _/_e_t_c_/_n_e_t_s_v_c_._c_o_n_f determines sudoers source order on AIX + +EEXXAAMMPPLLEESS + EExxaammppllee llddaapp..ccoonnff + # 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=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 + # + # 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 + + SSuuddooeerrss sscchheemmaa ffoorr OOppeennLLDDAAPP + The following schema, in OpenLDAP format, is included with ssuuddoo source + and binary distributions as _s_c_h_e_m_a_._O_p_e_n_L_D_A_P. Simply copy it to the + schema directory (e.g., _/_e_t_c_/_o_p_e_n_l_d_a_p_/_s_c_h_e_m_a), add the proper include + line in _s_l_a_p_d_._c_o_n_f and restart ssllaappdd. Sites using the optional on-line + configuration supported by OpenLDAP 2.3 and higher should apply the + _s_c_h_e_m_a_._o_l_c_S_u_d_o file instead. + + 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 ) + + attributetype ( 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 ) + ) + +SSEEEE AALLSSOO + cvtsudoers(1), ldap.conf(4), sssd-sudo(4), sudo.conf(4), sudoers(4) + +AAUUTTHHOORRSS + Many people have worked on ssuuddoo over the years; this version consists of + code written primarily by: + + Todd C. Miller + + See the CONTRIBUTORS file in the ssuuddoo distribution + (https://www.sudo.ws/contributors.html) for an exhaustive list of people + who have contributed to ssuuddoo. + +CCAAVVEEAATTSS + Note that there are differences in the way that LDAP-based _s_u_d_o_e_r_s is + parsed compared to file-based _s_u_d_o_e_r_s. See the _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _L_D_A_P + _a_n_d _n_o_n_-_L_D_A_P _s_u_d_o_e_r_s section for more information. + +BBUUGGSS + If you feel you have found a bug in ssuuddoo, please submit a bug report at + https://bugzilla.sudo.ws/ + +SSUUPPPPOORRTT + Limited free support is available via the sudo-users mailing list, see + https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search + the archives. + +DDIISSCCLLAAIIMMEERR + ssuuddoo 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 ssuuddoo or https://www.sudo.ws/license.html for + complete details. + +Sudo 1.8.26 November 9, 2018 Sudo 1.8.26 |