| AD-kerberized nfs4 mount fails | ||
|---|---|---|
 | Part I. Miscellaneous subjects (and those still to be sorted) |  |
| AD-kerberized nfs4 mount fails | ||
|---|---|---|
| | Part I. Miscellaneous subjects (and those still to be sorted) | |
August 2014
Abstract
Authenticating against the Active Directory domain Kerberos server works. Yet mounting Kerberized NFS4 shares fails. And how to fix it (for now).
Table of Contents
The Ubuntu host my-company-112-113.subdomain.mycompany.com has a hostname (unqualified) that is longer than 19 characters.
Whereas DNS allows 63 bytes, Windows specifies that the sAMAccountName of a host cannot be longer than 20 characters.
So the host cannot join the domain unders its hostname.
No problem: it can join under another string. Its IP number for example.
But then all of a sudden this fails with access denied:
my-company-112-113.subdomain.mycompany.com:~$ sudo mount nfsserver.mycompany.com:/home/apprentice /home/apprentice
It turns out that rpc.gssd, which does the authentication on behalf of the NFS daemon on the machine, searches for a few well known names in the keytab.
One of them is “<HOSTNAME>$”. Another is “host/<fqdn>”.
In my case, the first isn't there, but the second is, so it finds that one.
In AD Kerberos, the second is just an alias (a servicePrincipalName) for the actual name that was used to join the domain, and Windows forbids authentication with a servicePrincipalName.
So authentication of the host fails, and access to the share is denied.
| |  | |
| Part I. Miscellaneous subjects (and those still to be sorted) |  | Solution |