Last day at work I had to get working sudo and ldap. I’m not gonna get into a discussion about if it’s worth or not to use sudo. I can just say from my own experience, if you have a large number of users and hosts, they are clearly distinguishable and you are using roles (i.e = sysadmin, backup, any kind of group…) it’s totally worth.
Moreover, bear in mind you would have to update every sudo config file , definitely would be tedious, and here’s when LDAP gets in.
I brought into play two virtual machines, both of them running Solaris 10. Commonly I prefer doing that before making some huge mistake in a real environment, so here’s what I did. I called box0 to the client and ldapbox to the server. The rest of the post, I’ll assume you have set up a Directory Server and Native LDAP client service working fine. Summary:
Extending Schema
This step is pretty straightforward, you only need to add the schema to your directory instance, and restart the server. Assuming your instance might be in the default path /var/opt/SUNWdsee/dsins1/config/schema/99users.ldif.
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'
)
Now you only need to restart the server.Why do I need to restart my server? The matter is, the first time you started your server, the file was read into memory, so any change you make later will not have effect, at least you restart the instance.
LDAP support for sudo
You will need to get the source code of sudo and at least 1.7 version or upper. The reason is because earlier versions will not read nsswitch.conf. I used sudo-1.7.2p7, you can get it from Sunfreeware. Of course if you want to compile you will need to solve some dependencies, here is the list, however you had better confirm by yourself.
/---|(Sudo)
|-* gcc-3.4.6-sol10-x86-local
|-* libiconv-1.13.1-sol10-x86-local
|-* libintl-3.4.0-sol10-x86-local
|-* openssl-1.0.0a-sol10-x86-local
/---|( OpenLdap )
|- * db-4.7.25.NC-sol10-x86-local
|- * libtool-2.2.6b-sol10-x86-local
|- * sasl-2.1.21-sol10-x86-local
|- * openldap-2.4.22-sol10-x86-local
At this point and after installing all the dependencies we just need to compile:
./configure --with-ldap && make
Those people who like tinkering with Unix tools, is time to call ldd and take a look into sudo.
libpam.so.1 => /lib/libpam.so.1
libdl.so.1 => /lib/libdl.so.1
* libldap-2.4.so.2 => <em><b>(/usr/local/lib/libldap-2.4.so.2)</b></em>
* liblber-2.4.so.2 => <em><b>(/usr/local/lib/liblber-2.4.so.2)</b></em>
libintl.so.8 => /usr/local/lib/libintl.so.8
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libc.so.1 => /lib/libc.so.1
libcmd.so.1 => /lib/libcmd.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libgen.so.1 => /usr/lib/libgen.so.1
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2
libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libsec.so.1 => /usr/lib/libsec.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libavl.so.1 => /lib/libavl.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libm.so.2 => /lib/libm.so.2
If the LDAP libraries does not appear remember to add the path:
# crle -l -u PATH_TO_LIBRARIES</b>
Obviously I wouldn’t like having to install OpenLdap in all my clients (if you want to apply to more than one), so I thought to carry just with the libraries I needed. In a nutshell, we have just extended the schema and also enabled ldap support for sudo. The two last points for the next post.