Every time we added this, an error cropped up:
A project I’m working on requires a Kerberos and LDAP infrastructure. Most technology projects are easy to do badly, and more difficult to do well – and documented.
We use LetsEncrypt to issue a certificate to each server, and OpenLDAP can take the certificate and use it to encrypt and authenticate connections from other LDAP servers.
One of the problems I encountered was when setting up replication between servers. We use SaltStack to build and maintain our server estate, so deployment and configuration needs to be automated. This normally means spending a week automating a process which you’ll only do twice – once when you install it, and once again when you’re rebuilding the server and have forgotten everything you’ve done.
To secure OpenSSL, add this LDIF file to your directory:
dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/letsencrypt/live/ldap1.example.com/fullchain.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/letsencrypt/live/ldap1.example.com/cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/letsencrypt/live/ldap1.example.com/privkey.pem
Every time we did this, a vague error popped up:
$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f ./ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80)
Restarting slapd, the LDAP daemon, with full debugging showed nothing, neither did running the daemon through strace.
Several days of painful troubleshooting followed. We eventually found the issue – the LDAP daemon wasn’t able to access the TLS certificates! AppArmor was blocking access to the files under /etc/letsencrypt, and so we did two simple things.
First, we used setfacl to give the openldap user ‘rx’ permissions on /etc/letsencrypt/live and /etc/letsencrypt/archive:
$ sudo setfacl -m user:openldap:r-x /etc/letsencrypt/live $ sudo setfacl -m user:openldap:r-x /etc/letsencrypt/archive
This lets the LDAP daemon read and following the symbolic links in the live directory to the actual files.
Next, we needed to tell AppArmor to let the LDAP daemon, slapd, access the files themselves. It’s as easy as creating a file called /etc/apparmor.d/local/usr.sbin.slapd with the following:
/etc/letsencrypt/live/{{ grains.id }} r,
/etc/letsencrypt/archive/{{ grains.id }} r,
/etc/letsencrypt/archive/{{ grains.id }}/** r,
The trailing comma on the last line isn’t a mistake – if you don’t include it, AppArmor won’t install the rule. I won’t admit how long it took us to realise this!
Very helpful article Peter! Would you mind telling me which “setfacl” settings you had?
Cheers,
Daniel
If I’ve understood your question correctly, here’s what I have in the Salt state file:
ldap-access-to-machine-live-dir: acl.present: - name: /etc/letsencrypt/live - acl_type: user - acl_name: openldap - perms: rx ldap-access-to-machine-archive-dir: acl.present: - name: /etc/letsencrypt/archive - acl_type: user - acl_name: openldap - perms: rxI think you meant “sudo setfacl -m user:openldap:r-x /etc/letsencrypt/live” and “sudo setfacl -m user:openldap:r-x /etc/letsencrypt/archive”
Definitely as @Drotak wrote it, I had to find out it the hard way…
YEEEEEEEEEEEESSSS! FINALLY! THANK YOU!
I can’t say how many hours I have read blogs and Stack articles which only gave half the story, or where someone hacked the permissions in a way most don’t want.
Your instructions about setfacl and the three lines for apparmor was what finally made it work.
I had already tried all kinds of combinations of permissions for the directories and files, even manually copying the certificates elsewhere, and that didn’t work either.
Don’t forget to restart apparmor and slapd after adding the access exceptions.
service apparmor restart
service slapd restart