NFS4+Kerberos: Is the client authenticated?

Question

Imagine the following scenario: A company network with "domain joined" linux clients (e.g they have a HOST$@DOMAIN.LOCAL principal in their keytabs file + A computer entry in the DC). Now an attacker gains access to this network with his laptop (where he obviously has root privileges), he issues a kinit <valid_company_user> (lets assume he is in possession of the user's password and he started rpc.gssd with the -n parameter) and then mounts the user's nfs share (which is secured with kerberos).

Is this scenario preventable? (e.g enforce that the client is domain joined)

Initial testing suggested that there is some authentication going on (gssapi traffic between nfs-server and kdc after the client connects) but later experiments showed that this is most likely not client authentication but user verification. I've done a lot of research regarding this topic but non of the resources found could give me a definitive answer.

• [1] https://serverfault.com/questions/699114/does-kerberised-nfsv4-securely-protect-against-a-malicious-client-spoofing-the
• [2] https://www.spinics.net/lists/linux-nfs/msg88295.html
• [3] https://serverfault.com/questions/446768/error-reading-keytab-file-krb5-keytab

Answer 1

In NFS with RPCSEC_GSS v1, machine and user authentication are independent. The machine keytab is only used for initial mount setup RPCs (and callbacks, and UID 0), whereas RPCs sent on behalf of a non-root user are only authenticated with that user's tickets but not the machine's. It is entirely possible to perform the initial mount using the user's credentials as well (just usually not done for reasons).

RPCSEC_GSS v3 (as defined in RFC 7861) would be able to support compound machine+user authentication, but currently Linux does not implement this version at all. (It might one day, as it also adds features necessary for server-to-server file copy.)

However, Windows KDCs support "FAST armoring", where the user's AS-REQ (the initial ticket request) itself is sent encrypted using another ticket, e.g. machine credentials or an anonymous ticket obtained via PKINIT. Windows also supports requiring that such requests always be armored, meaning that the KDC would refuse a plain kinit from a non-member machine.

Linux clients using SSSD will be able to talk to such KDCs if krb5_use_fast is enabled – though I'm not sure about Winbind.

(Originally FAST was meant to only act as a secure transport and protect the AS exchange, and e.g. in Heimdal Kerberos it is more likely to be used with anonymous PKINIT as the armor ticket source, which wouldn't help you at all. However, Windows also uses FAST for compound authentication – adding machine claims to the user's PAC, if I have the right terminology – so it will most likely require a machine ticket instead; Linux servers don't support using claims, but for your purposes it should be enough to just require FAST usage in general.)