Fooblog

Most people who use *nix systems are probably familiar with sudo. At a customer I’ve been working for there used to be a vast machine park with sudo installations, all slightly different in configuration. Maintaining these configurations was not an easy task. Enter LDAP. Using LDAP for storing the sudo configuration we can now have a single point for configuring sudo, with instant updates on all machines.
I’ll explain what needs to be done to ldap-i-fy your sudo configuration below.

Put the following schema in your ldap config

---

dn: cn=schema
attributeTypes: ( 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 X-ORIGIN 'SUDO' )
attributeTypes: ( 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 X-ORIGIN 'SUDO' )
attributeTypes: ( 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 X-ORIGIN 'SUDO' )
attributeTypes: ( 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 X-ORIGIN 'SUDO' )
attributeTypes: ( 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 X-ORIGIN 'SUDO' )
objectClasses: ( 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 $ sudoOption $ description ) X-ORIGIN 'SUDO' )


---

Restart your ldap server(s) to include the schema

Build sudo with the configure options ‘–with-ldap=<path$gt;’ and –with-ldap-conf-file=/etc/sudo.ldap

Put new sudo binaries on your system(s)

Create /etc/sudo.ldap with the following contents, replacing the ip’s and dc’s


host 10.20.30.40 10.20.30.50
sudoers_base ou=SUDOers,dc=example,dc=com


Create an ldif file with your sudo config (see below for an example)

---


dn: ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
description: SUDO Configuration Subtree
ou: SUDOers

dn: cn=defaults,ou=SUDOers,dc=example,dc=com
cn: defaults
sudooption: ignore_dot
sudooption: !mail_no_user
sudooption: !root_sudo
sudooption: log_host
sudooption: logfile=/var/log/sudolog
sudooption: !syslog
sudooption: timestamp_timeout=10
objectClass: top
objectClass: sudoRole
description: Default sudoOption’s

dn: cn=Rule1,ou=SUDOers,dc=example,dc=com
cn: Rule1
sudooption: !authenticate
objectClass: top
objectClass: sudoRole
sudohost: ALL
sudocommand: /some/command
sudocommand: /some/other/command
sudouser: ALL
description: Allowed without password for ALL users

---

The first block of code contains the container for the rest of the sudo configuration, just leave this as-is. The second block contains the default options for sudo. Configure these to your liking, they are the same as for the non-ldap config, and are documented in the manual-page.

The third code-block lists a sample sudo rule. Repeat these as often as needed. The fields ’sudohost’, ’sudocommand’ and ’sudouser’ are required, ’sudooption’ is optional, and can override the defaults specified above.

Sudocommand should be repeated for every single executable (or use wildcards, not recommended) you want to enable via sudo. Sudouser can take regular usernames, or unix-group names when prefixed by a percent sign (%).

Please note that although commands can be negated (!/some/binary) there are work-arounds, so please think before acting. Users and Hosts can NOT be negated using ldap-configs… this is a current limitation.