Cant delete SSSD cached user

freeipasssd

Im testing a FreeIPA integration. One of the scenarios I'm trying is taking the server offline and making tests with the client, but I am facing an issue.
I have logged in on the client with a newly created FreeIPA user, than I stopped the FreeIPA server and SSH-ed again to the client . So far so good.

But I cant find a way to delete the cached FreeIPA user. I tried sss_cache -E but it does not help. As far as I can tell the account_cache_expiration setting in /etc/sssd/sssd.conf should delete the cached user after given time but it is 0 (unlimited time) by default

I'm using server with CentOS 7.4/FreeIPA 4.5.0 and client with Linux Mint 18.3/SSSD 1.13.4

PS:
This question is about similar issue but remain unanswered sssd and ldap authentication cache

Best Answer

sss_cache doesn't delete the cache on purpose, because then you'd have no way of logging to an offline client, the cached passwords are (so far) stored in the same cache as the rest of the data.

If you really want to remove the cache, one of the sssctl subcommands does that.

But selectively removing one entry is not possible. btw if you removed the user from the server, just requesting the user while the client is online should help.

Related Solutions

Using FreeIPA for centralized sudo – using SSSD for sudoers

Make sure your configuration follows a simple setup described here: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html

Ok, since I made that simple setup after verifying it works on RHEL 6.x and Fedora 18, I wish you had specified more details to help you.

Here is my working example with Fedora 19 (test sudo packages with RHEL 6.5 fixes forward ported):

[root@id ~]# nisdomainname 
example.com
[root@id ~]# sudo -U admin -l
Matching Defaults entries for admin on this host:
    requiretty, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR
    LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
    LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User admin may run the following commands on this host:
    (root) /usr/bin/bash
[root@id ~]# LANG=en_US.utf8 ipa sudorule-show admins --all
  dn: ipaUniqueID=83814998-68c1-11e3-a7ad-001a4a418612,cn=sudorules,cn=sudo,dc=example,dc=com
  Rule name: admins
  Enabled: TRUE
  User Groups: admins
  Hosts: id.example.com
  Sudo Allow Commands: /usr/bin/bash
  RunAs External User: root
  ipauniqueid: 83814998-68c1-11e3-a7ad-001a4a418612
  objectclass: ipaassociation, ipasudorule
[root@id ~]# su - admin
[admin@id ~]$ sudo /usr/bin/bash
[sudo] password for admin: 
[root@id admin]# exit
[admin@id ~]$

Do you have nisdomainname defined?

Linux / AD integration with SSSD: how to choose what systems a user can log into

I would recommend against using the filter based access control filters for most deployments for two reasons:

they are hard to get right
the filters are applied on the user entry that is logging in. This might have interesting consequences especially if the filter contains a memberof attribute while the user is a member of nested groups - since the user entry only contains memberofs to direct parents, the nested groups would never match.

For very simple use cases, such as allowing a user or a group of users, I would recommend to use the simple access provider

For complex use-cases, SSSD supports AD GPOs starting with the 1.12.x series, search the sssd-ad man page for details.

Best Answer

Related Solutions

Using FreeIPA for centralized sudo – using SSSD for sudoers

Linux / AD integration with SSSD: how to choose what systems a user can log into

Related Topic