[Freeipa-users] ipa-client-install failure
Rob Crittenden
rcritten at redhat.com
Sat Mar 21 16:05:00 UTC 2015
Roberto Cornacchia wrote:
> Indeed, id admin does not work and there is no sign of it in the log.
>
> From the client (with admin-tools installed):
>
> $ kinit admin
> Password for admin at HQ.EXAMPLE.COM <mailto:admin at HQ.EXAMPLE.COM>:
> $ ipa user-show admin
> User login: admin
> Last name: Administrator
> Home directory: /home/admin
> Login shell: /bin/bash
> UID: 1172000000
> GID: 1172000000
> Account disabled: False
> Password: True
> Member of groups: trust admins, admins
> Kerberos keys available: True
> $ id admin
> id: admin: no such user
> $ getent passwd admin at hq.spinque.com <mailto:admin at hq.spinque.com>
> $ grep admin /var/log/sssd/*
> $
This is because sssd is not configured in nsswitch.conf to serve
anything other than sudo.
I see in the client install log you posted in the first message of the
thread that there was no pre-existing sssd.conf so it created a new one,
but that shouldn't be an issue.
What does sssd.conf look like and is sssd running?
rob
>
>
> On 21 March 2015 at 01:01, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>> wrote:
>
> On 03/20/2015 07:40 PM, Roberto Cornacchia wrote:
>> Two log files in attachment (the other files in /var/log/sssd are
>> all empty).
>>
>> I'll also go through the troubleshooting page again, thanks
>>
>
> Do the logs include an id call for admin?
> I do not see any instance of the word "admin" in the log.
>
>
>>
>> On 20 March 2015 at 23:03, Dmitri Pal <dpal at redhat.com
>> <mailto:dpal at redhat.com>> wrote:
>>
>> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
>>> SSSD logs are empty so far.
>>
>> This is wrong.
>>
>>> Isn't sssd.conf written by ipa-client-install?
>>
>> Yes
>>
>>> If I raise the debug level after client installation,
>>
>> (and restart)
>>
>>> what activities do you suggest to attempt from the client?
>> the ones that fail. getent call that returns nothing.
>> Also try 'id'.
>>
>> http://www.freeipa.org/page/Troubleshooting#Client_Installation
>> https://fedorahosted.org/sssd/wiki/Troubleshooting
>>
>>>
>>>
>>> On 20 March 2015 at 22:37, Dmitri Pal <dpal at redhat.com
>>> <mailto:dpal at redhat.com>> wrote:
>>>
>>> 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.
>>>
>>>
>>> --
>>> 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
>
>
>
>
More information about the Freeipa-users
mailing list