Sometimes your LDAP-backed user vanishes from getent passwd, but the home directory and UID/GID are still intact. This article walks through recovering a lost LDAP user from the SSSD cache, manually restoring essential attributes without losing access to the user’s files or profile.

🧠 The Problem Link to heading

You’re on a Linux workstation joined to an Active Directory domain via SSSD. A previously working LDAP user (jdoe) suddenly can’t log in:

  • getent passwd jdoe returns nothing.
  • su - jdoe fails or gives fallback shell issues.
  • The home directory /home/jdoe still exists with the correct UID/GID.

You don’t want to recreate the user, as doing so could mismatch permissions, destroy cache links, or trigger audit noise.

🛠️ Goal Link to heading

Recover the user from the local SSSD cache, ensuring:

  • UID/GID stays consistent.
  • Home directory and files are preserved.
  • Shell access is fully restored.
  • No temporary users are needed.

🔍 Root Cause Link to heading

Using sssctl and ldb-tools, we determined the cached user entry was missing critical fields like:

  • homeDirectory
  • loginShell

Without these, PAM/SSSD couldn’t correctly resolve the user for login.

📦 Requirements Link to heading

Install the tools:

sudo apt install ldb-tools

Also, switch to the root shell (sudo -i) for ease of operations.

🧪 Step-by-Step: User Resurrection Link to heading

1. Backup the SSSD DB Link to heading

First, stop SSSD and back up the cache:

sudo systemctl stop sssd
sudo cp -a /var/lib/sss/db /var/lib/sss/db.bak

2. Identify the Cache Database Link to heading

Look for your domain’s cache DB, typically in:

ls /var/lib/sss/db/cache_*.ldb

Let’s assume it’s:

/var/lib/sss/db/cache_CORP.EXAMPLE.COM.ldb

3. Locate the User DN Link to heading 

ldbsearch -H /var/lib/sss/db/cache_CORP.EXAMPLE.COM.ldb 'name=jdoe@example.com' dn

You should get output like:

dn: name=jdoe@example.com,cn=users,cn=CORP.EXAMPLE.COM,cn=sysdb

4. Edit the Cached Entry Link to heading

Use ldbedit to modify the user entry:

ldbedit -H /var/lib/sss/db/cache_CORP.EXAMPLE.COM.ldb name=jdoe@example.com --editor=vi

In the opened record, if you don’t see the following lines, add them:

loginShell: /bin/bash
homeDirectory: /home/jdoe

Then save and exit.

5. Restart SSSD Link to heading 

sudo systemctl restart sssd

✅ Validate It Worked Link to heading 

getent passwd jdoe

Expected output:

jdoe:*:1953422651:1953400513:John Doe:/home/jdoe:/bin/bash

Now test login:

su - jdoe

Boom 💥 — you’re back in.

🧼 Final Notes Link to heading

  • This fix is cache-based — it restores function but doesn’t correct upstream AD/LDAP issues.
  • It’s a safe emergency fix when full rejoin or user recreation would be destructive or overkill.
  • Keep the backup (db.bak) around until you’re confident everything is stable.

🧙‍♂️ Pro Tip Link to heading

Need to browse the cache in bulk? Dump it like this:

ldbsearch -H /var/lib/sss/db/cache_CORP.EXAMPLE.COM.ldb > /tmp/sss_cache.ldif

Then grep your way to clarity.

📌 Conclusion Link to heading

When LDAP fails you and your user is caught in limbo, SSSD’s cache is your savior. With a bit of surgical editing and restraint, you can recover a fully working user session — no lost files, no mismatched UIDs, no drama.

Happy hacking! 🛠️

Written by a DevOps Engineer who refuses to lose data on their watch.