NFS4 mount fails with AD Kerberos and long hostnames
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
nfs-utils (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Hi,
Version info:
Using Ubuntu 14.04 LTS 'Trusty', and nfs-utils 1.2.8.
Symptoms:
Mounting kerberized NFS4 shares fails when the host is joined to an Active Directory domain, but not with the conventional name. Non-kerberized mounts succeed. Hosts joining the domain with the conventional name for their principal and/or sAMAccountName can also mount.
My Analysis:
When a host joins an Active Directory domain, it is convention to use the upper case non-fully-qualified domain name followed by a '$' as a principal name. But Windows cannot handle names longer than 19 characters. So when using longer hostnames, another string must be used, e.g. the IP number.
NFS looks only for <HOSTNAME>$, and fails if no principal by that name exists. AD forbids authentication with host/<fqdn> or nfs/<fqdn>. The manpage of 'msktutil' states that setting the userPrincipalName to host/<fqdn> should fix that. But in my case, it doesn't. And in many cases, it is impractical (requiring elevated privileges on Windows).
Included is a patch of utils/gssd/
[appdefaults]
nfs = {
ad_
}
I'm not sure whether to offer this patch here, to Debian, upstream, or all three.
Also, it makes use of an otherwise rarely used corner of Kerberos: appdefaults.
Regards
Jurjen
The attachment "Make NFS look for configurable AD principal" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]