[Freeipa-users] [SOLVED] Re: gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) - SOLVED

Dmitri Pal dpal at redhat.com
Mon Dec 2 04:18:30 UTC 2013


On 12/01/2013 06:34 PM, Les Stott wrote:
> Alexander, Petr, Martin,
>
> Sorry for the delay, was the weekend. 
>
> With your guidance I have figured out the issue. Using tcpdump I saw some references to a NIS domain that had been setup on the box. This was different to the domain name I setup for freeipa. Arp was also only showing short hostnames.
>
> I modified /etc/nsswitch.conf so that nis was not in the picture....
>
> Hosts files dns
>
> Then the ipa-client-install ran without problems. (It reset nsswitch.conf back to include nis afterwards)
>
> Installing keyutils fixed the other error too.
>
> Thanks for all your help.
>
> Regards,
>
> Les
>
> -----Original Message-----
> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] 
> Sent: Saturday, 30 November 2013 12:32 AM
> To: Les Stott
> Cc: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing)
>
> On Fri, 29 Nov 2013, Les Stott wrote:
>> Hi,
>>
>> Recently installed freeipa on two servers in multi-master mode. We want to have a central authentication system for many hosts. Environment is RHEL 6.4 for servers, RHEL 6.1 for the first client host, standard rpm packages used - ipa-server-3.0.0-26.el6_4.4.x86_64 and  ipa-client-3.0.0-37.el6.x86_64.
>>
>> I am now trying to add the first linux host to freeipa via ipa-client-install.
>>
>> When I run ipa-client-install on a host in debug mode it fails with 
>> errors below  (I have changed hostnames and ip's, 
>> freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com 
>> 192.168.1.23, host client - host1 192.168.1.15)
>>
>> trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com
>> get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: 
>> GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
>> information (Server ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos 
>> database)
>> {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
>> failure.  Minor code may provide more information (Server 
>> ldap/freeipa-1 at MYDOMAIN.COM not found in Kerberos database)', 'desc': 
>> 'Local error'}
>>
>> The Kerberos logs on the server (free-ipa-1) show Nov 29 01:46:14 
>> freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16 
>> 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0,  admin@ MYDOMAIN.COM for 
>> HTTP/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database
>>
>> The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM<mailto:freeipa-1 at MYDOMAIN.COM>). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at MYDOMAIN.COM<mailto:freeipa-1.mydomain.com at MYDOMAIN.COM>. I can see these in the web interface. I believe this is where it is stumbling.
>>
>> I've been banging my head against the wall on this one for a couple of days. Everything I've found says make sure you have working dns, make sure you can reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on server has ip's for servers listed with fqdn first and shortname second. I've done all that.
>>
>> I am using external dns (not integrated with freeipa), and have populated all records required as per sample config files provided during install. My time servers are other servers too, but that shouldn't matter, everything is in sync.
>>
>> ; for Kerberos Auto Discovery
>> ; ldap servers
>> _ldap._tcp              IN SRV 0 100 389        freeipa-1.mydomain.com.
>> _ldap._tcp              IN SRV 0 100 389        freeipa-2.mydomain.com.
>>
>> ;kerberos realm
>> _kerberos               IN TXT MYDOMAIN.COM
>>
>> ; kerberos servers
>> _kerberos._tcp          IN SRV 0 100 88         freeipa-1.mydomain.com.
>> _kerberos._tcp          IN SRV 0 100 88         freeipa-2.mydomain.com.
>> _kerberos._udp          IN SRV 0 100 88         freeipa-1.mydomain.com.
>> _kerberos._ucp          IN SRV 0 100 88         freeipa-2.mydomain.com.
>> _kerberos-master._tcp   IN SRV 0 100 88         freeipa-1.mydomain.com.
>> _kerberos-master._tcp   IN SRV 0 100 88         freeipa-2.mydomain.com.
>> _kerberos-master._udp   IN SRV 0 100 88         freeipa-1.mydomain.com.
>> _kerberos-master._udp   IN SRV 0 100 88         freeipa-2.mydomain.com.
>> _kpasswd._tcp           IN SRV 0 100 464        freeipa-1.mydomain.com.
>> _kpasswd._tcp           IN SRV 0 100 464        freeipa-2.mydomain.com.
>> _kpasswd._udp           IN SRV 0 100 464        freeipa-1.mydomain.com.
>> _kpasswd._udp           IN SRV 0 100 464        freeipa-2.mydomain.com.
>>
>> ;ntp server
>> _ntp._udp               IN SRV 0 100 123        ntp1.mydomain.com.
>> _ntp._udp               IN SRV 0 100 123        ntp2.mydomain.com.
>>
>> Reverse dns entries are also available and both freeipa servers and the host I am trying to configure ipa-client on can do lookups and receive fqdn's. They can all do reverse lookups that resolve correctly.
>>
>> I have read that when using SASL/GSSAPI (Kerberos) authentication, its possible that the service provider sets the principal name (SPN) to "ldap/servername" in the TGS_REQ based on a dns query of the PTR record. I do have PTR's configured, and they have FQDN's. Is it true that this happens with GSSAPI? If so how can I get around that?
>>
>> Reverse Zone File for 192.168.1
>> 22  PTR   freeipa-1.mydomain.com.
>> 23  PTR   freeipa-2.mydomain.com.
>>
>> Nslookup results for each IP:
>> 22.1.168.192.in-addr.arpa      name = freeipa-1.mydomain.com.
>> 23.1.168.192.in-addr.arpa      name = freeipa-2.mydomain.com.
>>
>> I can authenticate using kinit before running the script and it still doesn't work.
>>
>> The short version of running the install shows:
>> Discovery was successful!
>> Hostname: host1.mydomain.com
>> Realm: MYDOMAIN.COM
>> DNS Domain: mydomain.com
>> IPA Server: freeipa-1.mydomain.com
>> BaseDN: dc=mydomain,dc=com
>>
>> It authenticates correctly with the admin user for enrolling the host, but joining the realm fails.
>>
>> I've tried everything I can think of.
> Can you show your resolv.conf?
> Can it be that it actually misses
>     domain mydomain.com
> stanza?
>
>
>
> --
> / Alexander Bokovoy
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

Marking the thread as solved.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the Freeipa-users mailing list