SSSD logs are empty so far.
Isn't sssd.conf written by ipa-client-install? If I raise the debug level
after client installation, what activities do you suggest to attempt from
the client?


On 20 March 2015 at 22:37, Dmitri Pal <d...@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
> $ ntpdate ipa.hq.example.com
> $ ldapsearch -x -h 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 ad...@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 ad...@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 krb5kdc[9229](info): AS_REQ (6 etypes
> {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com
> for krbtgt/hq.example....@hq.example.com, Additional pre-authentication
> required
> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes
> {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes
> {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/
> hq.example....@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 <d...@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 <d...@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.cornacc...@gmail.com> wrote:
>>>
>>>>  No, sorry about the confusion, i shouldn't have posted so quickly.
>>>>
>>>> When I use the correct domain (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" <d...@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
>>>>> 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.cornacc...@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
>>>>>>  Realm: HQ.EXAMPLE.COM
>>>>>> DNS Domain: hq.example.com
>>>>>> IPA Server: 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 ad...@hq.example.com:
>>>>>> Successfully retrieved CA cert
>>>>>>     Subject:     CN=Certificate Authority,O=HQ.EXAMPLE.COM
>>>>>>     Issuer:      CN=Certificate Authority,O=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
>>>>>> 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
>>>>>> 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 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
>
-- 
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

Reply via email to