On Thu, Mar 07, 2019 at 09:15:30AM +0100, Morgan Marodin wrote:
Sorry, could I try to delete and recreate the trust?
Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin <morgan(a)marodin.it>
ha scritto:
> 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?
Hi,
I think recreate the trust won't help. It looks like a DNS issue. Please
check if
host -t SRV
_kerberos._udp.IPA.MYDOMAIN.COM
or
host -t SRV
_kerberos._udp.IPA.MYDOMAIN.COM
return this DC or any other AD DCs. Only IPA servers should be returned
here.
bye,
Sumit
> >
> > Thanks
> >
> > Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose <sbose(a)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(a)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(a)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(a)mydomain.com <
> >> > >> morgan.marodin(a)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
> >> > >>
> >> > >
> >>
> >