#8963 Security. After removing external group mapped to Active Directory group from POSIX group, all AD users of this AD group still have their previous access privileges.
Opened 2 years ago by cwojciech. Modified 2 years ago

Issue

After removing external group mapped to Active Directory group from POSIX group, all AD users of this AD group still have their access privileges, as they had before removal.

Steps to Reproduce

Prerequisites:
- FreeIPA Server: VERSION: 4.9.2, API_VERSION: 2.240 on AlmaLinux 8.4/CentOS 8.4
- One-way trust established IPA to AD (i.e. “domain.ad”),
- Client hosts with ipa client configured and registered in FreeIPA - exist and running.

  1. On FreeIPA create external group i.e. “external-ad-map”
  2. On FreeIPA add AD user group i.e. “AD-GROUP@domain.ad” as external member object to IPA group “external-ad-map”
  3. On FreeIPA create POSIX group i.e. “host-admins”
  4. On FreeIPA add group “external-ad-map” as member of POSIX group “host-admins”.
  5. Create HBAC rule for POSIX group “host-admins” accessing client host (group of client hosts) with sshd, sudo ….
  6. Create Sudo rule for the “host-admins” group to allow to execute some or all root commands on above client host (group of client hosts).
  7. Check with HBAC Test the possibility of accessing client hosts with rules created above. Try AD user (i.e. “johnbrown@domain.ad”), member of Windows user group AD-GROUP. Result is “access granted”
  8. Login as "jonbrown@domain.ad" to client hosts covered by above HBAC and Sudo rules. Access according to HBAC and Sudo rules is granted, works OK.
  9. Then remove group “external-ad-map” from POSIX group “host-admins”.
  10. Check with HBAC Test the possibility of accessing client hosts with rules created above. Try AD user (i.e. “johnbrown@domain.ad”), member of Windows user group AD-GROUP. Result is “access denied” as it should be.
  11. Try to login as "jonbrown@domain.ad" to client hosts covered by HBAC and Sudo rules for group “host-admins”. Real access with privileges of HBAC and Sudo rules of POSIX group "host-admins" is still granted …..

Actual behavior

See above, p. 9, 10, 11.

Expected behavior

Members of AD group removed from IPA POSIX group shouldn't have access to resources, they had before removal.

Version/Release/Distribution

ipa-server-4.9.2-4.module_el8.4.0+2501+94d209c1.x86_64
ipa-client-4.9.2-4.module_el8.4.0+2501+94d209c1.x86_64
389-ds-base-1.4.3.16-16.module_el8.4.0+2505+fc96bc48.x86_64
pki-ca-10.10.5-3.module_el8.4.0+2467+635979e4.noarch
krb5-server-1.18.2-8.el8.x86_64


Hi,

as explained in How SSSD works, SSSD is caching information related to users and groups. The cache configuration can be tuned, please refer to man sssd.conf(5) and especially the settings related to entry_cache_sudo_timeout, entry_cache_user_timeout and entry_cache_group_timeout.
The doc Cached Entries Information also explains how to retrieve information about a cached entry.

Hi,
Described behavior doesn't depend on sssd cache. Please check (after point 11):
- execute #sss_cache -E on IPA servers and clients
- on Windows AD server remove user "jonbrown@domain.ad" from group AD-GROUP
- try to login to client host as "jonbrown@domain.ad" - unsuccessful
- execute #sss_cache -E on IPA servers and clients
- on Windows AD server add user "johnbrown@domain.ad" to group AD-GROUP again
- try to login to client host as "johnbrown@domain.ad" - SUCCESS .....


On client (and server):
sssdctl user-checks johnbrown@domain.ad

... user id... etc,
IDs - ok
......

testing pam_acct_mgmt

pam_acct_mgmt: Permission denied

PAM Environment:
- no env -


User johnbrown@domain.ad can still access client host ....

Can you bump up the sssd debug level and capture this behavior? I'm not sure the sss_cache -E is doing what you expect it is.

cc @sbose

Login to comment on this ticket.

Metadata