It's one of our local Domain Controller, in this site there is 2 DC.
Could I try to delete and recreate the trust? Or do you have other suggestions?

Thanks

Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose <sbose@redhat.com> ha scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
> Sorry, any news from my logs?

sorry for the delay. What kind of server is 192.168.0.15? It looks like
the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns
'Realm not local to KDC' when getting a request for this realm.
Additionally it looks like it cannot decrypt IPA-AD cross-realm tickets.

bye,
Sumit

>
> Please let me know, thanks.
> Morgan
>
> Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin <morgan@marodin.it>
> ha scritto:
>
> > You can find attached a tar.gz file with the logs of the server and the
> > testing client, captured after done a restart of the *sssd* daemon and a *sss_cache
> > -E* command, on both parts.
> > I sanitized all logs, a long work!
> >
> > Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose <sbose@redhat.com> ha
> > scritto:
> >
> >> On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
> >> > The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group
> >> > *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active
> >> > Directory.
> >> > I tested the *id morgan.marodin@mydomain.com <
> >> morgan.marodin@mydomain.com>*
> >> > command both in the client and the server, they differ only for the last
> >> > part *,219402407(ad_ipa_admins)*.
> >> > I can see it in the client, not in the server.
> >>
> >>
> >> That explains the changing behaviour on the client. The client gets all
> >> group memberships from the server and it looks like the server once in a
> >> while has issues to add the IPA group memberships to AD users.
> >>
> >> Please add now debug_level=9 to the [nss] and [domain/...] sections on
> >> an IPA server and restart SSSD. Then please try to reproduce the state
> >> where ad_ipa_admins is missing. For this you can try to restart SSSD and
> >> call the id command afterwards or calling 'sss_cache -E' to invalidate
> >> the cached data before calling id.
> >>
> >> If you change sssd.conf on the servers it would be helpful to see a
> >> (sanitized) version of sssd.conf as well.
> >>
> >>
> >> bye,
> >> Sumit
> >>
> >