I also observed one peculiar thing when it comes to group membership of the
group which is used in my HBAC rule.
When I issue getent group ad_users on the server, I get:
ad_users:*:101025:j...@td.mydomain.com
In the FreeIPA's web UI membership looks like follows:
External member
> On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via FreeIPA-users
> wrote:
>
>
> The ipa-client gets all its data from the IPA server and for efficiency
> the lookup on the server goes via the SSSD cache on the server.
>
> While on the client during auth
What was the IPA version you used? It might be not related, but when i upgraded
sssd to 1.15.2-5 ssh doesn't work for me neither on the FreeIPA server, nor on
the clients. What's more strange, getent passwd for AD users doesn't work for
the clients, although it works for the server.
> On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via FreeIPA-users
> wrote:
>
>
> The ipa-client gets all its data from the IPA server and for efficiency
> the lookup on the server goes via the SSSD cache on the server.
>
> While on the client during auth
> On Fri, Jul 14, 2017 at 10:00:20AM -0000, bogusmaster--- via FreeIPA-users
> wrote:
>
> yes, but I think this is only a side effect. SSSD cannot resolve a
> global catalog server. Does
>
> dig SRV _gc._tcp.td.mydomain.com
>
> return anything when called on
Thank you for the answer.
I've verified the status of domain on both server and client.
On a server it appears that IPA domain (ipa.sub.mydomain.com) is always online.
However, status of AD domain (sub.mydomain.com) seems to be fluctuating between
Online and Offline and sometimes sssctl returns
Thank you for sharing this hint, I am going to try the upgrade. Can I ask you
which version of IPA did you use with that sssd version? Did you upgrade sssd
on each type of server (I mean both client and server)?
Many thanks,
Bart
___
FreeIPA-users
Hi All,
I am setting up a one-way trust from FreeIPA server to AD domain with a
pre-shared key.
It seems that it was set up successfully but I cannot verify the Kerberos
configuration when I follow the steps described here:
Behavior that I described above pertains to Windows 2008 R2. When I attempt at
doing exactly the same with AD set up on top of Windows 2012, it works
flawlessly. Unfortunately, environment I have to set up trust with uses Windows
2008 R2. I am wondering what might be the difference between
