On ajoute une ligne automount, au même titre que les lignes passwd, group et shadow déjà modifiées pour nslcd (Section 4.4, « Configurer l'accès transparent à l'annuaire depuis le client »).

grep ^automount /etc/nsswitch.conf ||\
  echo -e "\nautomount:      ldap" | sudo tee -a /etc/nsswitch.conf

Trois fichiers sont à écrire ou compléter :

cat << 'SCRIPT_EOF' >configure-autofs.sh
#!/usr/bin/env bash
# ==============================================================================
# configure-autofs.sh
# Configures autofs on Debian GNU/Linux to query LDAP maps over LDAPS
# using SASL/GSSAPI with the machine's host Kerberos principal.
# ==============================================================================
set -euo pipefail

readonly DOMAIN="lab.local"
readonly REALM="${DOMAIN^^}"
readonly CLIENT_FQDN="clnt.${DOMAIN}"
readonly HOST_PRINCIPAL="host/${CLIENT_FQDN}@${REALM}"
readonly KEYTAB_FILE="/etc/krb5.keytab"

# Validate host keytab presence
if [[ ! -s "${KEYTAB_FILE}" ]]; then
  echo "[-] Error: System keytab '${KEYTAB_FILE}' not found or empty." >&2
  echo "    Ensure 'install-lab-host-keytab.sh' was executed successfully." >&2
  exit 1
fi

echo "=== 1. Configuring /etc/nsswitch.conf for automount ==="
if grep -q '^automount:' /etc/nsswitch.conf; then
  if ! grep -E '^automount:.*\<ldap\>' /etc/nsswitch.conf >/dev/null; then
    sed -i -E 's/^(automount:[[:space:]]*)(.*)$/\1\2 ldap/' /etc/nsswitch.conf
  fi
else
  echo "automount:      files ldap" >> /etc/nsswitch.conf
fi

echo "=== 2. Writing /etc/default/autofs ==="
cat << 'EOF' > /etc/default/autofs
# Master map entry point in LDAP DIT
MASTER_MAP_NAME="ou=auto.master,ou=automount,dc=lab,dc=local"
TIMEOUT=300
BROWSE_MODE="no"
LOGGING="verbose"

# LDAP Target URI (native LDAPS on port 636)
LDAP_URI="ldaps://ldap-srvr.lab.local"
SEARCH_BASE="ou=automount,dc=lab,dc=local"

# Schema mapping corresponding to autofs.schema (RFC 2307bis extended)
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="automountInformation"

# Explicit path to the credentials configuration file
AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
EOF

echo "=== 3. Writing /etc/autofs_ldap_auth.conf (SASL/GSSAPI) ==="
# Notes:
# - usetls/tlsrequired are set to "no" as transport is natively wrapped in ldaps://.
# - authtype="GSSAPI" with clientprinc instructs autofs to authenticate
#   directly using the machine credentials stored in /etc/krb5.keytab.
# - Omitting 'user' prevents Cyrus SASL from injecting an incompatible authzid.
cat << EOF > /etc/autofs_ldap_auth.conf
<?xml version="1.0" ?>
<autofs_ldap_sasl_conf
    usetls="no"
    tlsrequired="no"
    authrequired="yes"
    authtype="GSSAPI"
    clientprinc="${HOST_PRINCIPAL}"
/>
EOF

chmod 600 /etc/autofs_ldap_auth.conf
chown root:root /etc/autofs_ldap_auth.conf

echo "=== 4. Restarting autofs service ==="
systemctl restart autofs

echo ""
echo "[+] Success: autofs configured against LDAP using GSSAPI machine authentication."
SCRIPT_EOF
sudo bash configure-autofs.sh

Note

La confidentialité de la connexion entre automount et l'annuaire est déjà assurée par l'URI ldaps://ldap-srvr.lab.local : l'attribut usetls de autofs_ldap_auth.conf, qui commande l'utilisation de StartTLS sur une connexion ldap:// en clair, reste donc à no, exactement comme nslcd/ldap-starttls l'a été pour nslcd (Section 4.4, « Configurer l'accès transparent à l'annuaire depuis le client »). La confiance dans l'autorité de certification labCA est héritée du fichier /etc/ldap/ldap.conf déjà déployé sur ce client (Section 4.2, « Sécuriser les échanges avec TLS et l'authentification SASL/GSSAPI »), commun à tous les outils construits sur libldap.

systemctl status autofs

sudo systemctl status autofs
● autofs.service - Automounts filesystems on demand
     Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-09-07 18:13:10 CEST; 5s ago
 Invocation: 17385f2a553d43438154449af7ef1fb3
       Docs: man:autofs(8)
    Process: 5743 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /var/run/autofs.pid (code=exited, status=0/SUCCESS)
   Main PID: 5744 (automount)
      Tasks: 5 (limit: 971)
     Memory: 3.7M (peak: 4.8M)
        CPU: 69ms
     CGroup: /system.slice/autofs.service
             └─5744 /usr/sbin/automount --pid-file /var/run/autofs.pid

sept. 07 18:13:10 clnt systemd[1]: Starting autofs.service - Automounts filesystems on demand...
sept. 07 18:13:10 clnt (automount)[5743]: autofs.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS
sept. 07 18:13:10 clnt automount[5744]: Starting automounter version 5.1.9, master map ou=auto.master,ou=automount,dc=lab,dc=local
sept. 07 18:13:10 clnt automount[5744]: using kernel protocol version 5.06
sept. 07 18:13:10 clnt automount[5744]: reading ldap master ou=auto.master,ou=automount,dc=lab,dc=local
sept. 07 18:13:10 clnt automount[5744]: connected to uri ldaps://ldap-srvr.lab.local
sept. 07 18:13:10 clnt automount[5744]: reading ldap map ldap:ou=auto.home,ou=automount,dc=lab,dc=local
sept. 07 18:13:10 clnt automount[5744]: mounted indirect on /ahome with timeout 300, freq 75 seconds
sept. 07 18:13:10 clnt systemd[1]: Started autofs.service - Automounts filesystems on demand.

La ligne connected to uri ldaps://ldap-srvr.lab.local confirme que le démon a bien authentifié son bind avec le principal machine host/clnt.lab.local@LAB.LOCAL : un keytab absent ou périmé, ou une unité ou=automount encore fermée à l'accès anonyme, se traduirait ici par une erreur GSS-API error ou Insufficient access et l'absence du point de montage indirect /ahome.

L'option sec=krb5p ne se limite pas à sécuriser la négociation du montage : elle impose, pour chaque opération RPC ultérieure (ouverture de répertoire, lecture, écriture), la construction d'un contexte RPCSEC_GSS propre à l'identifiant numérique de l'utilisateur qui effectue l'appel. Ce contexte ne peut être construit qu'à partir d'un ticket Kerberos appartenant à cet utilisateur : c'est le rôle du démon rpc.gssd, qui recherche un tel ticket dans les caches présents sous /tmp.

Or aucune des identités déployées jusqu'ici n'est un ticket personnel : le principal host/clnt.lab.local (Q : Q192) authentifie la machine, et le compte nslcd-proxy (Section 4.4, « Configurer l'accès transparent à l'annuaire depuis le client ») authentifie un service. Ni l'un ni l'autre ne circule au nom d'anakin. Vérifiez qu'aucun ticket personnel n'a été délivré.

klist

klist: No credentials cache found while getting default ccache

C'est cette absence de ticket, et non l'échec d'une authentification, qui provoque le refus Permission non accordée : la connexion elle-même a réussi via le compte nslcd-proxy côté NSS/PAM, mais aucun mécanisme n'a jamais demandé de ticket Kerberos pour anakin lui-même.

Le paquet libpam-krb5 déclenche cette commande automatiquement lors de son installation : le module est donc déjà intégré à la pile d'authentification commune depuis la partie Section 3.4, « Installer et initialiser le service Kerberos ». Vérifiez sa présence, aux côtés du module fourni par libpam-ldapd.

grep -nE 'pam_krb5|pam_ldap' /etc/pam.d/common-auth

17:auth   [success=3 default=ignore]      pam_krb5.so minimum_uid=1000
19:auth [success=1 default=ignore]      pam_ldap.so minimum_uid=1000 use_first_pass

La pile PAM examine ces lignes dans leur ordre d'apparition : le premier module qui réussit interrompt les suivants grâce à son contrôle [success=N default=ignore]. Le numéro de ligne renvoyé par grep -n permet de vérifier lequel des deux modules est sollicité en premier :

Sur le serveur, réutilisez les fichiers ~/.ldap_<uid>_pass pour créer, ou resynchroniser si le principal existe déjà, un principal par compte.

cat << 'SCRIPT_EOF' >provision-skywalker-principals.sh
#!/usr/bin/env bash
set -euo pipefail

readonly DOMAIN="lab.local"
readonly REALM="${DOMAIN^^}"
readonly USERS=(padme anakin leia luke)

echo "=== 1. Provisioning Kerberos principals from the LDAP secrets ==="
for user in "${USERS[@]}"; do
  PASS_FILE="${HOME}/.ldap_${user}_pass"
  if [[ ! -s "${PASS_FILE}" ]]; then
    echo "Error: Secret not found in ${PASS_FILE}." >&2
    exit 1
  fi
  USER_PASS=$(head -n 1 "${PASS_FILE}")

  sudo kadmin.local -q "addprinc -pw ${USER_PASS} ${user}@${REALM}" >/dev/null 2>&1 || \
  sudo kadmin.local -q "cpw -pw ${USER_PASS} ${user}@${REALM}" >/dev/null 2>&1
  echo "  - ${user}@${REALM} : principal is synchronised with the LDAP directory"
done

echo -e "\nSuccess: Skywalkers' family Kerberos principals are provisioned in the realm ${REALM}"
SCRIPT_EOF
bash provision-skywalker-principals.sh

=== 1. Provisioning Kerberos principals from the LDAP secrets ===
  - padme@LAB.LOCAL : principal is synchronised with the LDAP directory
  - anakin@LAB.LOCAL : principal is synchronised with the LDAP directory
  - leia@LAB.LOCAL : principal is synchronised with the LDAP directory
  - luke@LAB.LOCAL : principal is synchronised with the LDAP directory

Success: Skywalkers' family Kerberos principals are provisioned in the realm LAB.LOCAL.

Contrôlez la liste des principaux du royaume, en complément de la Section 3.4, « Installer et initialiser le service Kerberos ».

sudo kadmin.local -q "listprincs" | grep -E '^(padme|anakin|leia|luke)@LAB.LOCAL'

anakin@LAB.LOCAL
leia@LAB.LOCAL
luke@LAB.LOCAL
padme@LAB.LOCAL

	Attention
	Le mot de passe Kerberos et le mot de passe LDAP de chaque compte sont désormais deux secrets distincts, qui ne restent identiques qu'à l'instant de ce script : un changement de mot de passe ultérieur d'un seul côté (par exemple via passwd côté PAM) romprait cette synchronisation. Ce support ne traite pas cette question, qui relève de la fédération d'identités.

Depuis le client, reprenez exactement la même commande : aucune reconfiguration n'est nécessaire côté client, puisque pam_krb5.so était déjà en place (Section 3.4, « Installer et initialiser le service Kerberos ») et n'attendait que l'existence du principal.

su - anakin

Password:
anakin@clnt:~$ pwd
/ahome/anakin
anakin@clnt:~$ klist

Ticket cache: FILE:/tmp/krb5cc_10001_WeX3hF
Default principal: anakin@LAB.LOCAL

Valid starting       Expires              Service principal
07/09/2026 18:34:14  08/09/2026 04:34:14  krbtgt/LAB.LOCAL@LAB.LOCAL
        renew until 08/09/2026 18:34:14
07/09/2026 18:34:14  08/09/2026 04:34:14  nfs/nfs-srvr.lab.local@LAB.LOCAL
renew until 08/09/2026 18:34:14

anakin@clnt:~$ ls -lAh

total 16K
-rw------- 1 anakin anakin   64  6 sept. 17:24 .bash_history
-rw-r--r-- 1 anakin anakin  220  6 sept. 17:22 .bash_logout
-rw-r--r-- 1 anakin anakin 3,5K  6 sept. 17:22 .bashrc
-rw-r--r-- 1 anakin anakin  807  6 sept. 17:22 .profile

Le ticket obtenu automatiquement par pam_krb5.so au nom du principal anakin@LAB.LOCAL permet désormais à rpc.gssd de construire le contexte RPCSEC_GSS attendu par le montage sec=krb5p : l'accès au répertoire personnel est cette fois complet, sans qu'aucun paramètre du montage NFSv4 lui-même n'ait changé.

Le tableau ci-dessous reprend, dans l'ordre de la progression, chaque brique validée et la commande qui en apporte la preuve.

Les deux dernières lignes bouclent la démarche : elles apportent, côté client, la preuve que les options de sécurité choisies dès l'écriture du fichier /etc/exports (Section 5.1, « Configurer l'exportation sur le serveur NFSv4 ») et reprises dans l'entrée automountInformation publiée dans l'annuaire (Section 6.3, « Publier la configuration de l'automontage dans l'annuaire ») sont bien celles qui protègent, de bout en bout, un montage auquel l'utilisateur accède réellement : ni la déclaration côté serveur, ni le montage lui-même, ne suffisent sans le ticket Kerberos personnel mis en évidence dans la Section 7.2, « Diagnostiquer et compléter l'authentification Kerberos par utilisateur ».