Task 007: Making sudo work with LDAP

This was intended to be a part of Task 006: Setting up LDAP, but turned out to be a bigger job than expected. It's because (1) hard to debug (2) LDAP sucks on CLI (3) the internet is flooded with outdated/dangerous tutorials.

Configuring LDAP for sudo (server)

Install sudo-ldap, an LDAP-aware sudo variant.
```
apt install sudo-ldap
```
Register database schema for sudo data.

LDAP should learn about the structure of sudoers data. This can be done by adding schema to it. The schema info is already provided by sudo-ldap.
```
ldapadd -Q -Y EXTERNAL -H ldapi:// -f /usr/share/doc/sudo-ldap/schema.olcSudo
```
On the internet, many people pickup old/broken tutorials and keep suggesting manual conversion of old-style schema or binding "cn=admin,cn=config". Nope, you don't do that. Those solutions might work, but are dirty and dangerous.
Add OU=SUDOer

Every sudo-related entry can be isolated under an independent OU. But, unfortunately, creating this requires writing LDIF, which is dirty:
```
dn: ou=SUDOers,dc=eon,dc=lan
objectClass: top
objectClass: organizationalUnit
ou: SUDOers
```
That was long. I saved this into sudoers-ou.ldif, and fed it to LDAP:
```
slapadd -l sudoers-ou.ldif
```
Insert sudoers data

sudo-ldap provides cvtsudoers tool, which converts /etc/sudoers to LDIF data, which can be directly added to the database.
```
cvtsudoers /etc/sudoers -b ou=SUDOers,dc=eon,dc=lan > sudoers.ldif
slapadd -l sudoers.ldif
```
Note that name collision b/w LDAP and local is a total bitch here. Combined w/ outdated cache, it's almost impossible to figure out what's going on. So DON'T use the same name for anything, even b/w users and groups.

Configuring sudo-ldap (client)

Install sudo-ldap:

apt install sudo-ldap

... and add following values to /etc/ldap/ldap.conf:

BASE    dc=eon,dc=lan
URI     ldap://ldap.eon.lan/
SUDOERS_BASE ou=SUDOers,dc=eon,dc=lan

A lot more details can be found in sudoers.ldap(5).

Additional Notes

If things don't work, it's likely that the server is not configured properly, rather than the client. There are two easy ways to debug the problem.
1. add SUDOERS_DEBUG 2 to /etc/sudo-ldap.conf (see sudoers.ldap(5)). This will show LDAP debug output while using sudo.
2. You can query the server manually:
```
  ldapsearch -x -h ldap.eon.lan "objectClass=sudoRole"
```
  If this shows nothing, your sever is to blame.
ldapadd can be used instead of slapadd, but both have pros and cons. slapadd assume local invocation by admin, so it's a lot simpler, but sometime it creates files with root ownership, causing permission error.

I'm leaving alternatve commands, just for the record:
```
 # This will create new files under /etc/ldap/. Use your `chmod`!
 slapadd -n 0 -l /usr/share/doc/sudo-ldap/schema.olcSudo
 # -n 0 : schemas MUST go into `cn=config`, which is in database #0

 ldapadd -x -D cn=admin,dc=eon,dc=lan -W -f sudoers.ldif 
```