On 24 Oct 2020, at 14:41, Alexander Bokovoy
On Sat, 24 Oct 2020, Vin??cius Ferr??o via FreeIPA-users wrote:
I???m aware that we can make overrides on AD users with the Default
Trust View object on IPA. I???ve created another one for specific users
named ???Clients Trust??? and added three user accounts there. Made the
overrides that I want, and when I checked with getent on a Linux
client, the overrides aren???t worked.
On the new ID view, there???s this Host options, so I checked two hosts
that I???m interested, and still didn???t override.
As a last resort I???ve reset sssd cache, with sss_cache -E, but no
So the question is: Is it supported to override AD users in other trust
than the default trust view? If yes how can I debug with the override
SSSD only refreshes individual ID view per host during restarts. And
yes, you need to clean up the cache if you changed which view applies to
which client. The reason for that is that changing UID/GID mapping for
existing processes running under those UID/GIDs is not possible (they
are set at start by kernel) unless application is specially made to
support it. Changing ID view is considered to be a potentially
destructive operation to existing machine state due to this.
'Default Trust View' is applied automatically by SSSD on the IPA
masters, thus any additional view should be applied explicitly to a
for details how ID views are supposed to work.
Thanks for in deed documentation, and as I can see I done the homework correctly.
My case seems to be the last grouped picture, the one with the subtitle: On this figure
there is no override in the default view defined for the AD object A. SSSD will return the
data from AD unmodified and the extdom plugin or the compat tree will override the
gidNumber if view xyz is requested for the AD object A.
And in fact is what I’ve done. But I didn’t changed UID/GID, I always keep this default, I
just populated missing data from AD: login shell, home and ssh keys. But it still does not
work as expected. I already rebooted both IPA server and the host.
And I still get wrong information:
[root@login ~]# getent passwd
Anything that I should be looking for?
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland