Linux: centralise accounts with LDAP, SSSD and PAM

The statutory auditor is back. In lab 2, you locked the account of ktraore, the dock agent who left months ago. The preliminary report fits in one sentence: ktraore is locked on srv-erp, but active on srv-quai, with administration rights, and the auditor logged in with a password found in the former contractor's notes. The group has had a central directory since last year, which nobody finished connecting. The follow-up visit is on Friday. You start by mapping the estate: the same employee carrying two different numbers from one server to the next, and a local account silently inheriting the directory's groups. You learn to read an LDAP directory, its branches, entries and filters, encrypting the connection and introducing yourself with an account that can only read. Then you disable the former employee in the directory, and discover that a central revocation is worth nothing as long as a local account carries the same name. The lab goes where tutorials stop. Connecting a server with SSSD, NSS and PAM, and understanding why SSSD refuses to start with a file readable by everyone. Migrating local accounts to the directory without any file changing hands, knowing why a chown run on the whole disk would steal their files from a container's accounts. Seeing that a badly chosen order reopens the door you thought was closed. Cutting the directory, seeing who can still get in thanks to the cache, and testing the emergency account before you need it. Finally, writing the departure procedure the auditor will read on Friday. The directory is a real OpenLDAP, and the dock server a container with its own SSSD: you work on a small estate, from a single terminal. At the end, real login attempts check your revocations, as the auditor will, and the result counts for your ranking.