Ce support de synthèse avait pour ambition de réunir, sur un seul couple serveur/client, les services d'identité et de stockage précédemment traités séparément dans Introduction aux annuaires LDAP avec OpenLDAP et Introduction au système de fichiers réseau NFSv4. Les objectifs annoncés en introduction (Section 2, « Objectifs ») sont atteints avec des résultats conformes : une architecture minimale où slapd, krb5-kdc, nfs-kernel-server et idmapd cohabitent sur le même système sans se gêner, grâce à des principaux Kerberos et des certificats TLS distincts par service ; des cartes autofs conformes à la RFC 2307bis, publiées et relues dans l'unité ou=automount ; et un chiffrement de bout en bout, aussi bien pour la consultation de l'annuaire (ldaps://, SASL/GSSAPI) que pour l'accès au système de fichiers réseau (sec=krb5p, xprtsec=tls:mtls).
La chaîne d'authentification annoncée dans les objectifs : pam_krb5 → nss_ldap → idmapd → mount NFSv4, a été diagnostiquée et vérifiée maillon par maillon dans la Section 8.2, « Diagnostiquer et compléter l'authentification Kerberos par utilisateur » : l'incident rencontré, un montage NFSv4 visible mais dont le contenu reste inaccessible, a montré concrètement qu'une authentification réussie (NSS/PAM via l'annuaire) ne suffit pas à satisfaire une exigence de sécurité posée au niveau du transport (sec=krb5p). Seul un ticket Kerberos personnel, obtenu par pam_krb5.so une fois le principal utilisateur provisionné, comble cet écart. La Section 8.3, « Valider l'accès transparent de bout en bout » a ensuite confirmé, commande par commande, que ces garanties ne restent pas de simples déclarations de configuration, mais s'appliquent bien au trafic réel entre les deux systèmes.
Ce résultat a un coût, qu'il convient de mettre en regard du bénéfice obtenu. Chaque accès à l'annuaire ou au partage réseau mobilise désormais un handshake TLS, l'obtention ou la vérification d'un ticket Kerberos, et le chiffrement systématique des données échangées : autant de cycles processeur et de latence qui n'existaient pas dans une configuration en clair, même si le déchargement matériel du chiffrement par tlshd et le noyau (kTLS) en limite fortement l'impact. À ce coût de fonctionnement s'ajoute un coût d'administration : gestion d'une autorité de certification, rotation des certificats et des keytab, et désormais synchronisation de deux secrets par compte utilisateur (mot de passe LDAP et mot de passe Kerberos), comme l'a rappelé la mise en garde de la Section 8.2, « Diagnostiquer et compléter l'authentification Kerberos par utilisateur ». Le bénéfice, en contrepartie, est celui d'une infrastructure dont le trafic reste inexploitable en cas d'interception, et dont l'accès aux ressources s'appuie sur une authentification forte plutôt que sur la seule confiance dans l'adresse réseau du client : une propriété désormais attendue de toute infrastructure exposée, y compris à l'intérieur d'un centre de données.
Cette maquette reste néanmoins celle d'un unique couple serveur/client. Passer à l'échelle en production soulève des questions que ce support n'aborde pas : réplication de l'annuaire LDAP (multi-maître ou MirrorMode) pour éliminer le point de défaillance unique que constitue ici ldap-srvr.lab.local ; haute disponibilité et répartition de charge du service NFSv4, par exemple avec pNFS ; distribution ou fédération du royaume Kerberos au-delà d'un unique KDC, avec une question de gouvernance désormais concrète : comment maintenir en synchronisation, à grande échelle, les identifiants d'un même utilisateur portés par deux systèmes distincts ; et automatisation du cycle de vie des certificats, plutôt que la gestion manuelle d'une autorité labCA unique. Autant de problématiques qui prolongent naturellement ce support de travaux pratiques.