[Freeipa-users] ipa-client-install failure

Dmitri Pal dpal at redhat.com
Fri Mar 20 21:37:09 UTC 2015


On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
> It certainly gets there, because the client gets in fact enrolled as a 
> domain host. I can see it from the UI in Identity / Hosts. But not in 
> the DNS zone.
>
> *Before ipa-client-install, all these do work: *
>
> $ ssh ipa.hq.example.com <http://ipa.hq.example.com>
> $ ntpdate ipa.hq.example.com <http://ipa.hq.example.com>
> $ ldapsearch -x -h ipa.hq.example.com <http://ipa.hq.example.com> -b 
> dc=hq,dc=example,dc=com uid=admin
>
>
> *After running ipa-client-install, all these do work:*
>
> $ kinit admin
> Password for admin at HQ.EXAMPLE.COM <mailto:admin at HQ.EXAMPLE.COM>:
> $ ipa dnszone-show --all
> [...]
> $ ntpq -p
>  remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *ipa.hq.example. 131.155.140.130  3 u   19   64    1    0.415   -0.006 
> 0.000
>  LOCAL(0)        .LOCL.           5 l    -   64    0    0.000  0.000   
> 0.000
>
> *But this does NOT work:*
> $ getent passwd admin at hq.example.com <mailto:admin at hq.example.com>

What do SSSD logs show on the client?
Please rise the SSSD debug_level and provide SSSD logs.

>
> *On the server, in /var/log/krb5kdc.log, I see many of these:*
>
> Mar 20 21:53:17 ipa.hq.example.com <http://ipa.hq.example.com> 
> krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 
> 192.168.0.207 <http://192.168.0.207>: NEEDED_PREAUTH: 
> admin at HQ.EXAMPLE.COM <mailto:admin at HQ.EXAMPLE.COM> for 
> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM <mailto:COM at HQ.EXAMPLE.COM>, 
> Additional pre-authentication required
> Mar 20 21:53:17 ipa.hq.example.com <http://ipa.hq.example.com> 
> krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 
> 192.168.0.207 <http://192.168.0.207>: ISSUE: authtime 1426884797, 
> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM 
> <mailto:admin at HQ.EXAMPLE.COM> for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM 
> <mailto:HQ.EXAMPLE.COM at HQ.EXAMPLE.COM>

This is not an error. It is a normal user authentication.
OK so it is DNS that is not working. Is DNS server running on the server?
What do Bind logs show?

>
> 192.168.0.207 is the IP of the client I'm trying to install. However, 
> higher up in the log, I also see such errors for the ipa server itself.
>
> On 20 March 2015 at 20:24, Dmitri Pal <dpal at redhat.com 
> <mailto:dpal at redhat.com>> wrote:
>
>     On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>>     No, all real machines.
>>
>>     I'm really sorry it's taking so much of your time.
>>     I had tried almost everything on a VM setting first, and
>>     everything was fine.
>>     Everything always works fine, until you actually need it.
>
>
>     We try to help as much as we can.
>     Can you do LDAP lookups as a directory manager from client host to
>     server?
>     Can you ssh from client to server?
>
>     When you try to install client is there anything in the logs on
>     the server? Does it even get there?
>
>
>
>
>>
>>
>>     On 20 March 2015 at 19:41, Dmitri Pal <dpal at redhat.com
>>     <mailto:dpal at redhat.com>> wrote:
>>
>>         On 03/20/2015 01:57 PM, Roberto Cornacchia wrote:
>>>         But the ipa server itself is also enrolled as a client, just
>>>         after the server installation, right?. And that worked fine.
>>
>>         Are these VMs?
>>         There have been a similar case when the network was not set
>>         properly for the virtual test environment.
>>
>>
>>>
>>>         On 20 March 2015 at 18:55, Roberto Cornacchia
>>>         <roberto.cornacchia at gmail.com
>>>         <mailto:roberto.cornacchia at gmail.com>> wrote:
>>>
>>>             No, sorry about the confusion, i shouldn't have posted
>>>             so quickly.
>>>
>>>             When I use the correct domain (hq.example.com
>>>             <http://hq.example.com>), then I really get all the same
>>>             errors as before, also in the new client.
>>>
>>>
>>>
>>>             On 20 Mar 2015 18:39, "Dmitri Pal" <dpal at redhat.com
>>>             <mailto:dpal at redhat.com>> wrote:
>>>
>>>                 On 03/20/2015 01:25 PM, Roberto Cornacchia wrote:
>>>>                 Oops. Not true, forget last email.
>>>>
>>>>                 This secon client installation went different just
>>>>                 because it took the wrong domain.
>>>>                 It used *example.com <http://example.com>* (what
>>>>                 was previously set) instead of *hq.example.com
>>>>                 <http://hq.example.com>*
>>>>
>>>>                 Uninstalled, tried again with
>>>>                 --hostname=photon.hq.example.com
>>>>                 <http://photon.hq.example.com>
>>>>                 And then it behaves precisely like the previous client.
>>>>
>>>>                 So something seems wrong in the server.
>>>>
>>>>                 On 20 March 2015 at 18:18, Roberto Cornacchia
>>>>                 <roberto.cornacchia at gmail.com
>>>>                 <mailto:roberto.cornacchia at gmail.com>> wrote:
>>>>
>>>>                     Update:
>>>>                     I tried from another client. Also FC21, same
>>>>                     network, same settings from the same DHCP.
>>>>                     But obviously it must have something different
>>>>                     because it partially succeeded.
>>>>
>>>>                     - I do not get errors about LDAP users.
>>>>                     - I do not get errors about DNS update
>>>>
>>>>                     However:
>>>>                     - I still get the initial error about NTP
>>>>                     - The host is enrolled, but not added to the
>>>>                     DNS zone
>>>>
>>>>                     Now, I don't care much about the previous
>>>>                     client. It was pretty much empty and can
>>>>                     re-install Fedora from scratch.
>>>>
>>>>                     But I'd like to understand if this is still a
>>>>                     problem.
>>>>                     It should be added to the zone, shouldn't it?
>>>>
>>>>                     $ ipa-client-install --mkhomedir
>>>>                     --ssh-trust-dns --force-ntpd
>>>>                     Discovery was successful!
>>>>                     Hostname: photon.example.com
>>>>                     <http://photon.example.com>
>>>>                     Realm: HQ.EXAMPLE.COM <http://HQ.EXAMPLE.COM>
>>>>                     DNS Domain: hq.example.com <http://hq.example.com>
>>>>                     IPA Server: ipa.hq.example.com
>>>>                     <http://ipa.hq.example.com>
>>>>                     BaseDN: dc=hq,dc=example,dc=com
>>>>
>>>>                     Continue to configure the system with these
>>>>                     values? [no]: yes
>>>>                     Synchronizing time with KDC...
>>>>                     *Unable to sync time with IPA NTP server,
>>>>                     assuming the time is in sync. Please check that
>>>>                     123 UDP port is opened.*
>>>>                     User authorized to enroll computers: admin
>>>>                     Password for admin at HQ.EXAMPLE.COM
>>>>                     <mailto:admin at HQ.EXAMPLE.COM>:
>>>>                     Successfully retrieved CA cert
>>>>                     Subject: CN=Certificate
>>>>                     Authority,O=HQ.EXAMPLE.COM <http://HQ.EXAMPLE.COM>
>>>>                     Issuer:  CN=Certificate
>>>>                     Authority,O=HQ.EXAMPLE.COM <http://HQ.EXAMPLE.COM>
>>>>                     Valid From:  Mon Mar 16 18:44:35 2015 UTC
>>>>                     Valid Until: Fri Mar 16 18:44:35 2035 UTC
>>>>
>>>>                     Enrolled in IPA realm HQ.EXAMPLE.COM
>>>>                     <http://HQ.EXAMPLE.COM>
>>>>                     Created /etc/ipa/default.conf
>>>>                     New SSSD config will be created
>>>>                     Configured sudoers in /etc/nsswitch.conf
>>>>                     Configured /etc/sssd/sssd.conf
>>>>                     Configured /etc/krb5.conf for IPA realm
>>>>                     HQ.EXAMPLE.COM <http://HQ.EXAMPLE.COM>
>>>>                     trying https://ipa.hq.example.com/ipa/json
>>>>                     Forwarding 'ping' to json server
>>>>                     'https://ipa.hq.example.com/ipa/json'
>>>>                     Forwarding 'ca_is_enabled' to json server
>>>>                     'https://ipa.hq.example.com/ipa/json'
>>>>                     Systemwide CA database updated.
>>>>                     Added CA certificates to the default NSS database.
>>>>                     Adding SSH public key from
>>>>                     /etc/ssh/ssh_host_rsa_key.pub
>>>>                     Adding SSH public key from
>>>>                     /etc/ssh/ssh_host_ed25519_key.pub
>>>>                     Adding SSH public key from
>>>>                     /etc/ssh/ssh_host_dsa_key.pub
>>>>                     Adding SSH public key from
>>>>                     /etc/ssh/ssh_host_ecdsa_key.pub
>>>>                     Forwarding 'host_mod' to json server
>>>>                     'https://ipa.hq.example.com/ipa/json'
>>>>                     *Could not update DNS SSHFP records.*
>>>>                     SSSD enabled
>>>>                     Configured /etc/openldap/ldap.conf
>>>>                     NTP enabled
>>>>                     Configured /etc/ssh/ssh_config
>>>>                     Configured /etc/ssh/sshd_config
>>>>                     Configuring hq.example.com
>>>>                     <http://hq.example.com> as NIS domain.
>>>>                     Client configuration complete.
>>>>
>>>>
>>>>
>>>>
>>>
>>>                 It is different. It does not have the same failure
>>>                 about admin as you had in the first email.
>>>                 So may be it is the permissions issue and a separate
>>>                 NTP issue?
>>>                 Did you play with any permissions on the server side?
>>>
>>>
>>>                 -- 
>>>                 Thank you,
>>>                 Dmitri Pal
>>>
>>>                 Sr. Engineering Manager IdM portfolio
>>>                 Red Hat, Inc.
>>>
>>>
>>>                 --
>>>                 Manage your subscription for the Freeipa-users
>>>                 mailing list:
>>>                 https://www.redhat.com/mailman/listinfo/freeipa-users
>>>                 Go to http://freeipa.org for more info on the project
>>>
>>>
>>>
>>>
>>
>>
>>         -- 
>>         Thank you,
>>         Dmitri Pal
>>
>>         Sr. Engineering Manager IdM portfolio
>>         Red Hat, Inc.
>>
>>
>>         --
>>         Manage your subscription for the Freeipa-users mailing list:
>>         https://www.redhat.com/mailman/listinfo/freeipa-users
>>         Go to http://freeipa.org for more info on the project
>>
>>
>>
>>
>
>
>     -- 
>     Thank you,
>     Dmitri Pal
>
>     Sr. Engineering Manager IdM portfolio
>     Red Hat, Inc.
>
>
>     --
>     Manage your subscription for the Freeipa-users mailing list:
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>     Go to http://freeipa.org for more info on the project
>
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150320/866d3bf9/attachment.htm>


More information about the Freeipa-users mailing list