#8903 Group membership of an AD user does not get updated
Closed: invalid by abbra. Opened by joffenbach.

Issue

The group membership of an AD user does not get updated, when the POSIX group that contains the external AD group, to which the AD user belongs, is added to or removed from another POSIX group. Everything works well and the user's group membership gets updated correctly when no external group is involved in the group hierarchy.

Steps to Reproduce

  1. Establish trust from your IPA domain ipa.mycompany.com to an AD domain ad.mycompany.com.
  2. Ensure that the AD user user@ad.mycompany.com is part of the AD group AD\IPA_Users.
  3. Create an external AD group ipa group-add --desc='AD users external map' --external ad_users_external.
  4. Create a POSIX group ipa group-add --desc='AD users' ad_users.
  5. Add the AD group to the FreeIPA external group as an external member: ipa group-add-member ad_users_external --external="AD\IPA_Users".
  6. Add the external group to the POSIX group ipa group-add-member ad_users --groups ad_users_external.
  7. Ensure that the group ad_users is allowed to login to the client node.
  8. Login to the client node as user@ad.mycompany.com, execute groups and you get the correct membership:
    user@ad.mycompany.com
    ipa_users@ad.mycompany.com
    ad_users@ipa.mycompany.com
  9. Create a POSIX group ipa group-add --desc='Test users' test_users.
  10. Add the user group ad_users to test_users.
  11. Login to the client node as user@ad.mycompany.com, execute groups and you get the incomplete membership:
    user@ad.mycompany.com
    ipa_users@ad.mycompany.com
    ad_users@ipa.mycompany.com
  12. Clear the cache on the IPA server sss_cache -E.
  13. Login to the client node as user@ad.mycompany.com, execute groups and you get the correct membership:
    user@ad.mycompany.com
    ipa_users@ad.mycompany.com
    ad_users@ipa.mycompany.com
    test_users@ipa.mycompany.com
  14. Remove the group ad_users from the group test_users.
  15. Login to the client node as user@ad.mycompany.com, execute groups and you get the incorrect membership:
    user@ad.mycompany.com
    ipa_users@ad.mycompany.com
    ad_users@ipa.mycompany.com
    test_users@ipa.mycompany.com
  16. Clearing the cache via sss_cache -E on the IPA server is not sufficient, the files have to be removed:
    $ systemctl stop sssd
    $ rm -f /var/lib/sss/db/*
    $ systemctl start sssd
  17. Login to the client node as user@ad.mycompany.com, execute groups and you get the correct membership: user@ad.mycompany.com ipa_users@ad.mycompany.com ad_users@ipa.mycompany.com

Actual behavior

Even playing around with memcache_timeout, entry_cache_user_timeout and entry_cache_group_timeout on the server-side does no result in a correct group membership even when the object has timed out in the cache.

Expected behavior

In the best case the group membership gets updated immediately on the server-side when a group hierarchy change occurs or at the latest when the corresponding object has timed out in the cache.

Configuration

Server-side (sssd.conf):

[domain/ipa.mycompany.com]
id_provider = ipa
ipa_server = ipa-srv1-t.ipa.mycompany.com
ipa_domain = ipa.mycompany.com
ipa_hostname = ipa-srv1-t.ipa.mycompany.com
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
ipa_server_mode = True
sudo_provider = ipa
autofs_provider = ipa
subdomains_provider = ipa
session_provider = ipa
hostid_provider = ipa
ignore_group_members = True
ldap_use_tokengroups = False
ldap_referrals = False
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout, ldap_use_tokengroups
[domain/ipa.mycompany.com/ad.mycompany.com]
auto_private_groups = True
ldap_user_search_base = ou=IT Betrieb,ou=AABenutzer,ou=mycompanysb,dc=ad,dc=mycompany,dc=com
ldap_group_search_base = cn=Domänen-Benutzer,cn=Users,dc=ad,dc=mycompany,dc=com???ou=IPA,ou=Gruppen,dc=ad,dc=mycompany,dc=com??
[sssd]
services = nss, pam, ifp, sudo
domains = ipa.mycompany.de
[nss]
homedir_substring = /home
memcache_timeout = 300
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
allowed_uids = ipaapi, root
[secrets]
[session_recording]

Client-side (sssd.conf):

[domain/ipa.mycompany.com]
id_provider = ipa
ipa_server = _srv_, ipa-srv2-t.ipa.mycompany.com
ipa_domain = ipa.mycompany.com
ipa_hostname = ipa-client1-t.ipa.mycompany.com
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
dyndns_update = True
dyndns_iface = *
krb5_store_password_if_offline = True
default_shell = /bin/bash
cache_credentials = True
entry_cache_timeout = 5400
entry_cache_user_timeout = 5400
entry_cache_group_timeout = 5400
entry_cache_service_timeout = 5400
entry_cache_sudo_timeout = 60
ldap_sudo_smart_refresh_interval = 60
ldap_sudo_full_refresh_interval = 21600
[sssd]
services = nss, pam, ssh, sudo
domains = ipa.mycompany.com
[nss]
homedir_substring = /home
memcache_timeout = 300
[pam]
offline_credentials_expiration = 3
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[secrets]
[session_recording]

Version/Release/Distribution

Server-side:

$ docker images
REPOSITORY               TAG              IMAGE ID       CREATED       SIZE
freeipa/freeipa-server   centos-8-4.9.2   b86e523d2e76   11 days ago   902MB
Within the container:
$ sssd --version
2.4.0

Client-side:

$ ipa-client-install --version
4.8.6
$ sssd --version
2.2.3

This is a wrong place to file this bug. You need to work with SSSD, not FreeIPA on this. Please consider opening an issue to https://github.com/sssd/sssd/issues

Metadata Update from @abbra:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)

Metadata