Work-around:
[root@client18 ~]#   ipa-client-install \
>     --enable-dns-updates \
>     --force-ntpd \
>     --hostname=client18.hunter.org \
>     --password=adminpassword \
>     --principal=admin \
>     --realm=HUNTER.ORG \
>     --ssh-trust-dns \
>     --unattended
Discovery was successful!
Hostname: client18.hunter.org
Realm: HUNTER.ORG
DNS Domain: hunter.org
IPA Server: ipa.hunter.org
BaseDN: dc=hunter,dc=org

Synchronizing time with KDC...
Enrolled in IPA realm HUNTER.ORG
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HUNTER.ORG
trying https://ipa.hunter.org/ipa/xml
DNS server record set to: client18.hunter.org -> 192.168.1.101
Forwarding 'host_mod' to server u'https://ipa.hunter.org/ipa/xml'
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.
[root@client18 ~]#

See ticket https://fedorahosted.org/freeipa/ticket/3026

Your machine is not configured with a fully-qualified hostname. If this client needs to act as a server (including sshd) then some Kerberos and SSL operations will eventually fail, sometimes in non-obvious ways.

Passing --hostname is a workaround but it just masks the underlying problem. Many Kerberos applications expect gethostname() to return a FQDN. This may not be particularly important for a machine that purely acts as a client which is one reason why the --hostname option exists. Just be aware of the limitations.

I found that Anaconda/Kickstart was not configuring the host name as I expected. The anaconda-ks.cfg created when manually configuring a new build uses syntax that causes error messages when used to automate the build:

network  --bootproto=dhcp --device=em1 --noipv6 --activate
network  --bootproto=dhcp --hostname=client18.hunter.org

I am still not sure of the correct syntax, but I have started configuring the hostname with hostnamectl from a script after the first boot and before ipa-client-install:

[root@client18 ~]# hostnamectl set-hostname client18.hunter.org --static
[root@client18 ~]# hostnamectl set-hostname "Client 18"         --pretty
[root@client18 ~]# hostnamectl
   Static hostname: client18.hunter.org
   Pretty hostname: Client 18
         Icon name: computer-desktop
           Chassis: desktop
        Machine ID: 69d27b356a94476da859461d3a3bc6fd
           Boot ID: 6de4efaf7efc44d88dedaa305bc9e7da
  Operating System: Fedora 18 (Spherical Cow)
       CPE OS Name: cpe:/o:fedoraproject:fedora:18
            Kernel: Linux 3.8.2-206.fc18.x86_64
      Architecture: x86_64
[root@client18 ~]#

I'm having the same issue on a client system with RedHat 6.4 that is trying to join an IDM domain, but the interesting thing is that if I do the following:

$ hostname   --->  myhost
$ hostname -A  -->   myhost.mydomain.xx
Hostname can retrieve the FQDN

Additionally, my /etc/sysconfig/network has 
HOSTNAME=myhost.mydomain.xx

I can manually try the work-around, but it sure would be nice to have this enhanced just a tad :-)

(In reply to John Montes from comment #4)
> I'm having the same issue on a client system with RedHat 6.4 that is trying
> to join an IDM domain, but the interesting thing is that if I do the
> following:
> 
> $ hostname   --->  myhost
> $ hostname -A  -->   myhost.mydomain.xx
> Hostname can retrieve the FQDN
> 
> Additionally, my /etc/sysconfig/network has 
> HOSTNAME=myhost.mydomain.xx
> 
> I can manually try the work-around, but it sure would be nice to have this
> enhanced just a tad :-)
Your 'hostname' output should be myhost.mydomain.xx, not 'myhost'. This is basic requirement for Kerberos use in IDM since we create all Kerberos service principals using FQDN and there are no aliases with short names for them, for obvious reasons (IDM allows hosts from different domains to be enrolled, so ipa-1.domain1.coma nd ipa-1.domain2.com can be enrolled at the same time).