Intermittent failures in IPA server: IPA groups are not mapped correctly (some or all ipa groups are missing).

[Miguel Hinojosa]

We're facing some intermittent failures in IPA server, where the corresponding IPA
groups are not mapped correctly (some or all ipa groups are missing).

Short description of the set up: 2 IPA server nodes, both have a trust with AD servers
that act as authenticators. The AD users get mapped based on Unix Attributes, and in IPA
they belong to certain IPA groups for granting them access to server groups and sudo
rules.

What we're facing now is what seems to be a cache corruption or at least alteration
with some information not being reflected in the cache. The workaround for now is to
delete the cache (sometime in the client only, but occasionally also needed to delete it
on the server). After that, the IPA groups are back again reported correctly, but
eventually, after some 5 or 10 minutes, the groups are wrong again and users can not login
(because they are not reported to belong to the group(s) that have access to the given
server). 

The issue started after we patched (yum update) the first node. We did then not run the
ipa-server-upgrade command after OS update. We have done it like a week after, and it
reported to have completed successfully. But still the malfunctioning persists.

Let us know which logs or config files we could provide you.

Thanks and regards

[Florence Blanc-Renaud]

On 3/23/21 10:38 AM, Miguel Hinojosa via FreeIPA-users wrote:
>  We're facing some intermittent failures in IPA server, where the
> corresponding IPA groups are not mapped correctly (some or all ipa groups are missing).
>  
>  Short description of the set up: 2 IPA server nodes, both have a trust with AD servers
> that act as authenticators. The AD users get mapped based on Unix Attributes, and in IPA
> they belong to certain IPA groups for granting them access to server groups and sudo
> rules.
>  
>  What we're facing now is what seems to be a cache corruption or at least alteration
> with some information not being reflected in the cache. The workaround for now is to
> delete the cache (sometime in the client only, but occasionally also needed to delete it
> on the server). After that, the IPA groups are back again reported correctly, but
> eventually, after some 5 or 10 minutes, the groups are wrong again and users can not login
> (because they are not reported to belong to the group(s) that have access to the given
> server).
>  
>  The issue started after we patched (yum update) the first node. We did then not run the
> ipa-server-upgrade command after OS update. We have done it like a week after, and it
> reported to have completed successfully. But still the malfunctioning persists.
>  
>  Let us know which logs or config files we could provide you. 
Hi,

which IPA + SSSD versions are installed on the server/client?
Your issue looks similar to https://pagure.io/freeipa/issue/8044 but 
this problem was fixed a while ago.

In order to troubleshoot, you can add debug_level = 9 to sssd.conf, see 
[1] for more information.

Does the id command return the correct list of groups on the master 
configured as trust controller (group id and group name are present in 
"id" output)?
Are the missing groups defined on AD side or on IPA side?

flo

[1] https://sssd.io/docs/users/troubleshooting.html
>  
>  Thanks and regards
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Florence Blanc-Renaud]

On 3/23/21 11:29 AM, Florence Blanc-Renaud wrote:
>  On 3/23/21 10:38 AM, Miguel Hinojosa via FreeIPA-users wrote:
> > We're facing some intermittent failures in IPA server, where the 
> > corresponding IPA groups are not mapped correctly (some or all ipa 
> > groups are missing).
> >
> > Short description of the set up: 2 IPA server nodes, both have a trust 
> > with AD servers that act as authenticators. The AD users get mapped 
> > based on Unix Attributes, and in IPA they belong to certain IPA groups 
> > for granting them access to server groups and sudo rules.
> >
> > What we're facing now is what seems to be a cache corruption or at 
> > least alteration with some information not being reflected in the 
> > cache. The workaround for now is to delete the cache (sometime in the 
> > client only, but occasionally also needed to delete it on the server). 
> > After that, the IPA groups are back again reported correctly, but 
> > eventually, after some 5 or 10 minutes, the groups are wrong again and 
> > users can not login (because they are not reported to belong to the 
> > group(s) that have access to the given server).
> >
> > The issue started after we patched (yum update) the first node. We did 
> > then not run the ipa-server-upgrade command after OS update. We have 
> > done it like a week after, and it reported to have completed 
> > successfully. But still the malfunctioning persists.
> >
> > Let us know which logs or config files we could provide you.
>  Hi,
>  
>  which IPA + SSSD versions are installed on the server/client?
>  Your issue looks similar to https://pagure.io/freeipa/issue/8044 but 
>  this problem was fixed a while ago.
>   
There is also this recent issue:
https://github.com/SSSD/sssd/issues/5534 IPA missing secondary IPA Posix 
groups in latest sssd 1.16.5-10.el7_9.7

>  In order to troubleshoot, you can add debug_level = 9 to sssd.conf,
> see 
>  [1] for more information.
>  
>  Does the id command return the correct list of groups on the master 
>  configured as trust controller (group id and group name are present in 
>  "id" output)?
>  Are the missing groups defined on AD side or on IPA side?
>  
>  flo
>  
>  [1] https://sssd.io/docs/users/troubleshooting.html
> >
> > Thanks and regards
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to 
> > freeipa-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/[e-mail]... 
> >
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> >
>

[Miguel Hinojosa]

Oh, seems totally related!
Thanks a lot. 

We will try downgrading sssd package and will update you.

Kind regards

[Miguel Hinojosa]

Thank you a lot Florence.
It worked perfectly, no issues after downgrade package on both nodes.

Kind regards

[Florence Blanc-Renaud]

On 3/24/21 8:20 AM, Miguel Hinojosa via FreeIPA-users wrote:
>  Thank you a lot Florence.
>  It worked perfectly, no issues after downgrade package on both nodes.
>   
Glad to know the workaround fixed your issue, and thanks for closing the 
loop.

flo