Solaris 10 as LDAP client (to OpenLDAP 2.4.x)

During the last couple of weeks I’ve been working on getting a central directory setup for my client, running on OpenLDAP 2.4. Not having worked with LDAP a lot before it proved quite a challenge, especially getting Solaris 10 to work with the LDAP server without any glitches.
In this document I’ll try and describe how this setup was made, because I have been unable to find a single consistent document describing all the intricate details.
At this time I have all my problems fixed (AFAIK), but during the setup phase I experienced various problems:

  • Solaris 10 not seeing any users from LDAP
  • Solaris seeing users, but not letting them log in
  • Log-in working from console, but not ssh
  • Passwordless login (pubkey) not working in SUN-SSH
  • Users being able to hack extra permissions for themselves
  • etc…. etc….etc…

The entire article has been moved to a more permanent location, as a page on this site. You can find it under the ‘Pages’ header on the right. Setting up ldap

Sudo with LDAP

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.
sudo cartoon xkcd

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.