+++ This bug was initially created as a clone of Bug #1268040 +++

Description of problem:

rpc.gssd first looks for an entry of the form <HOSTNAME>$@<DOMAIN>, which corresponds to the Active Directory machine account.  It assumes that <HOSTNAME> will be in uppercase because that's how the entry is created if the machine is joined to the domain using Samba.
    
But that's not necessarily the case if the another identity management solution (e.g. Centrify) is used... 

Upstream commit f7b42b9e (gssd: select non-conventional principal) allows the hostname used in the search for a keytab entry for the machine account to overridden.  However, in an environment with a lot of clients it may not be feasible to customize the krb5.conf on each of those clients. 

rpc.gssd should first look for an entry that matches the unmodified hostname and then convert it to uppercase and try again only if that failed.

Version-Release number of selected component (if applicable):
nfs-utils-1.3.2-11.fc23

How reproducible:
Easy

Steps to Reproduce:
Run rpc.gssd with -vvv and look at the logs

Actual results:

rpc.gssd searches for the machine account in all caps, for example:

Sep 28 16:40:03 smayhew-fedora rpc.gssd[7305]: Success getting keytab entry for 'SMAYHEW-FEDORA$@EXAMPLE.COM'

Expected results:

rpc.gssd should search for the machine account using the unmodified hostname (whether that be in lower case, mixed case, whatever) first.  Note in my example it fails to find a machine account keytab entry with the hostname in lower caes because I don't have one in my keytab... the point is that it did the search:

Oct  1 12:03:52 smayhew-fedora rpc.gssd[24163]: No key table entry found for smayhew-fedora$@EXAMPLE.COM while getting keytab entry for 'smayhew-fedora$@EXAMPLE.COM'
Oct  1 12:03:52 smayhew-fedora rpc.gssd[24163]: Success getting keytab entry for 'SMAYHEW-FEDORA$@EXAMPLE.COM'


Additional info:

The following patch posted to the linux-nfs list addresses this:
http://thread.gmane.org/gmane.linux.nfs/73980