Peter Hicks' Blog

A project I’m working on requires a Kerberos and LDAP infrastructure. As with most tech, it’s easy to do something quickly, but much harder to do it properly and get it documented.
One of the biggest problems I encountered was when setting up replication between LDAP servers. We use SaltStack to build and maintain our server estate, so deployment and configuration needs to be automated.
Using LetsEncrypt to issue a certificate to each server, OpenLDAP can take the certificate and use it to encrypt and authenticate connections from other LDAP servers. It’s meant to be simple – 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
This error kept cropping 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 with all debugging switched on resulted in nothing, and strace-ing the daemon whilst running was similarly fruitless.
Cutting to the chase, the problem was that the openldap user didn’t have access to the certificate symlinks, nor the certificates either, and that AppArmor was blocking access to the files under /etc/letsencrypt.
So how do we solve it?
First, using setfacl, give the openldap user rx permissions on /etc/letsencrypt/live and /etc/letsencrypt/archive. This will allow slapd to follow read and follow the symbolic links to the actual files in the archive directory. Next, add the following to /etc/apparmor.d/local/usr.sbin.slapd:
/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 an error – this will stop AppArmor blocking slapd access to the certificate symlink and the actual certificate, as above. Remember to restart AppArmor afterwards.
And that’s it.

I took delivery of a shiny HP LaserJet wireless printer recently. Setting it up on the office network was fairly easy once I’d connected it via a cable (and then disconnected it afterwards) – except it kept broadcasting an open wireless network (SSID) which anyone could use.
That’s not awesome, but on HP’s Support Forum, I found these instructions from a user who worked out how to disable the network:

1. Make sure you do not have a USB cable attached to your
2. Go to the web configuration portal for the printer
3. Go to the Networking tab> Wi-Fi Direct Setup
4. Set WiFi Direct to "On"
5. Set Connection Method to "Advanced"
6. Check the box "Do not broadcast the Wi-Fi Direct name"
7. Click "Apply"
8. Restart the printer
9. Verify you no longer see the SSID
10. Go back to the Wi-Fi Direct Setup and set the WiFi Direct setting to "off"

The fantastic Let’s Encrypt service lets you issue SSL/TLS certificates to devices without charge. It’s not everything you may want at the enterprise level, but for the professional in their home environment, it’s great.
I wanted to replace the self-signed certificate on an HP printer I had, but it wasn’t an easy process. I’ve documented it here so it can be useful to others too.
First, use certbot to generate your certificate. Run the command as follows:
certbot -d host.example.com --manual --preferred-challenges dns certonly
This will instruct you to add a TXT record to the DNS record for the host for authentication, after which you’ll receive your certificate.
To convert this in to a PKCS#12 file, suitable for loading on to the printer, use the following command:
openssl pkcs12 -export -out certificate.pfx -inkey config/live/host.example.com/privkey.pem -in config/live/host.example.com/cert.pem
The .pfx file can then be uploaded to the printer and it’ll use it immediately.

On installing an Ubuntu 16.04 desktop from scratch and putting Citrix Receiver on it, I found I couldn’t connect to one of the servers that I need to for work. The strange error suggested that the Citrix client doesn’t trust the VeriSign Class 3 Public Primary Certification Authority – G5.
This seemed confusing at first – I have the CA certificate in /usr/share/ca-certificates/mozilla. A quick look at where Citrix Receiver installed itself quickly found what was going on.
Citrix Receiver only has a handful of CA certificates installed in /opt/Citrix/ICAClient/keystore/cacerts, so if you’re connecting to a server with an SSL certificate other than the dozen or so in here, simply copy the .crt or .pem file and you’re sorted.

Last week, CIO Magazine reported on the shortfall in mainframe skills.
It reminded me of a situation I faced a couple of years ago. My team was preparing to write software which integrated with an IBM z/OS system, and I knew literally nothing about it. I didn’t need to know all the details, but I wanted to be able to talk to the system programmers coherently and be taken seriously. I didn’t know much about CICS, nor RACF, and I’d not even heard of RACF. I wanted to learn.
I am a self-starter, and I want to get my hands on the technology I’m going to use in my work life. From learning perl, PHP and SQL in the late 1990s so I could capture ISDN call log data over RADIUS, to buying a bunch of older Cisco equipment to bring me up to speed on VoIP, it’s worked stunningly well. I wanted to do the same with z/OS – not to become an overnight expert, but to be able to bridge the gap between Java developers and the people who ran the mainframe we were going to be using. It would make the whole project happen with much less friction.
After no more than an hour or so’s research, I found IBM wanted $900-or-so a year, on top of buying dedicated PC hardware just so I could run z/OS and spend a bit of time becoming familiar with it. But why? I can download any number of GNU/Linux distributions without charge, or evaluate most Microsoft products for several months without any hassle. Why can’t I do that with z/OS? There were several sites offering TSO and CICS access, but that was only from a user’s perspective. I wanted to peer inside and see what made it tick.
Luckily, the project succeeded and I learnt a fair amount about z/OS in the process, but it wasn’t as quick or easy as if I’d been able to spend some of my own time learning. In fact, when I was given access to a non-production CICS region with the software on the other side of our interface, I spent several hours of after-work time getting to know it, and came away being able to help our developers write an even better product than if I’d stayed in my pure consultancy role.
If IBM want to change the perception that mainframes are an enigma understood only by the balding and bearded stalwarts at large companies, they need to get people hooked. Make the latest release of z/OS and a suitable emulator available for download, and let the world see how great your software is.

I visited a customer site last week to collect a building access card and get set up on their email system. I managed to get both done within 30 minutes.
The impressive thing was that my Inbox already contained instructions on how to set up remote access to Webmail and my desktop via Citrix. All I needed was Google Authenticator or similar on my phone and that was it.
Why can’t all Enterprise IT departments be this efficient?