Feature: Authd NFS & Samba Documentation regarding Kerberos and ID Mapping

[ajm370]

Is there an existing request for this feature?

• [x] I have searched the existing issues and found none that matched mine

Describe the feature

Following on from discussion in #948 with @adombeck, there are improvements that can be made on Authd NFS and Samba integration / interoperability and associated documentation.

The Authd NFS documentation is well-written, however it instructs the reader to use a single keytab generated for a file server which has been configured with Kerberos and a KDC (in practice, many will have just AD domain-joined via SSSD in the past, with DC's being a KDC within said domain): https://github.com/ubuntu/authd/blob/main/docs/howto/use-with-nfs.md#step-2-copy-the-kerberos-keytab-file

This is not advisable from a security standpoint, as the KDC / DC will not be able to distinguish connections from any device using this keytab (the file server and all client devices, from the example documentation).

Additionally, both the Samba and NFS Authd documentation instruct the reader to obfuscate UID/GID mappings and force all files/directories to appear as owned by the connecting user. While files/directories which the user has no rights over will fail to be accessed or modified, it does reduce the UX, as they will be unable to see the actually ownership and group permissions on network files over NFS or Samba.

Describe the ideal solution

1. Keytab sharing is not advised, and client-side steps are detailed to enable the mounting of NFSv4 file shares instead.
2. ID mapping, so that UID/GID's are consistent on the Ubuntu file server (Authd configured) and Ubuntu desktop clients (Authd configured), so that the UX is significantly improved, and users are able to see the actual underlying permissions structure of directories/files which they are browsing.

Alternatives and current workarounds

1. Use SSSD/adcli for all client devices (via AD join), which defeats the point of using Authd (mutually incompatible solutions).
2. Significantly simply permissions structures on file server/s, so that users run into issues less frequently when trying to access files/directories that the GUI/terminal would have them believe they are able to at first glance.